worldwide open-source software - software:development:web:docs:web:api

api

anonymous@undisclosed.example.com (Anonymous) — Thu, 24 Apr 2025 15:37:03 +0000

Веб-API

При написании кода для Интернета доступно большое количество веб-API. Ниже приведен список всех API и интерфейсов (типов объектов), которые вы можете использовать при разработке своего веб-приложения или сайта.

Веб-API обычно используются с JavaScript, хотя это не всегда так.

Технические характеристики Это список всех доступных API.

А
API устройств вывода звука Экспериментальный
Б
API фоновой выборки Экспериментальный
Фоновая синхронизация Экспериментальный
Фоновые задачи
API обнаружения штрих-кода Экспериментальный
API батареи
Маяк
Bluetooth API Экспериментальный
API широковещательного канала
С
Стили счетчиков CSS
CSS Custom Highlight API Экспериментальный
API загрузки шрифтов CSS
API рисования CSS Экспериментальный
API свойств и значений CSS
API модели типизированных объектов CSS
CSSOM
API холста
API обмена сообщениями канала
API буфера обмена
API потоков сжатия
Консольный API
API выбора контактов Экспериментальный
API указателя содержания Экспериментальный
API магазина файлов cookie Экспериментальный
API управления учетными данными
Д
ДОМ
События ориентации устройства
Е
API кодирования
Зашифрованные мультимедийные расширения
API пипетки Экспериментальный
Ф
API FedCM Экспериментальный
Получить API
Файловый API
API файловой системы
API файлов и каталогов
Полноэкранный API
г
API геймпада
API геолокации
Геометрические интерфейсы
ЧАС
HTML DOM
API перетаскивания HTML
API дезинфицирующего HTML-кода Экспериментальный
История API
я
API обнаружения бездействия Экспериментальный
API захвата изображений Экспериментальный
ИндекседБД
Чернильный API Экспериментальный
API-интерфейс наблюдателя за пересечением
К
API клавиатуры Экспериментальный
л
API обработчика запуска Экспериментальный
API доступа к локальным шрифтам Экспериментальный
М
API возможностей мультимедиа
Захват мультимедиа и потоки
API сеанса мультимедиа
Расширения источника мультимедиа Экспериментальный
Запись медиапотока
Н
API навигации Экспериментальный
API сетевой информации Экспериментальный
п
API видимости страницы
API обработчика платежей Экспериментальный
API запроса платежа
API производительности
Периодическая фоновая синхронизация Экспериментальный
API разрешений
Картинка в картинке API
События указателя
API блокировки указателя
Попов API
API презентации Экспериментальный
API приоритетного планирования задач
Push-API
р
API отчетов Экспериментальный
Изменить размер API-интерфейса Observer
С
API захвата экрана
API ориентации экрана
API блокировки пробуждения экрана
API выбора
Сенсорный API
События, отправленные сервером
API сервис-воркеров
Хранилище
API доступа к хранилищу
Потоки
Т
Сенсорные события
API доверенных типов
U
События пользовательского интерфейса
URL API
API шаблонов URL-адресов Экспериментальный
API клиентских подсказок агента пользователя Экспериментальный
В
API вибрации
API просмотра переходов Экспериментальный
API виртуальной клавиатуры Экспериментальный
Визуальное окно просмотра
Вт
Веб-анимация
API веб-аудио
API веб-аутентификации
Веб-компоненты
API веб-криптографии
API веб-замков
Веб-MIDI-API
Веб-API NFC Экспериментальный
Веб-уведомления
API веб-ресурсов
API веб-речи
API веб-хранилища
API веб-воркеров
API веб-кодеков
WebGL
API-интерфейс веб-графического процессора Экспериментальный
WebHID-API Экспериментальный
Веб-OTP API
WebRTC
API веб-транспорта
WebUSB-API Экспериментальный
API веб-VR Нестандартный Устаревший
ВебВТТ
API устройства WebXR Экспериментальный
API веб-сокетов
API наложения оконных элементов управления Экспериментальный
Икс
XMLHttpRequest
Интерфейсы
Это список всех доступных интерфейсов (то есть типов объектов).

A

AbortController
AbortSignal
AbsoluteOrientationSensor
AbstractRange
Accelerometer Экспериментальный
AesCbcParams
AesCtrParams
AesGcmParams
AesKeyGenParams
AmbientLightSensor Экспериментальный
AnalyserNode
ANGLE_instanced_arrays
Animation
AnimationEffect
AnimationEvent
AnimationPlaybackEvent
AnimationTimeline
Attr
AudioBuffer
AudioBufferSourceNode
AudioContext
AudioData Экспериментальный
AudioDecoder Экспериментальный
AudioDestinationNode
AudioEncoder Экспериментальный
AudioListener
AudioNode
AudioParam
AudioParamDescriptor
AudioParamMap
AudioProcessingEvent Устаревший
AudioScheduledSourceNode
AudioSinkInfo Экспериментальный
AudioTrack
AudioTrackList
AudioWorklet
AudioWorkletGlobalScope
AudioWorkletNode
AudioWorkletProcessor
AuthenticatorAssertionResponse
AuthenticatorAttestationResponse
AuthenticatorResponse

B

BackgroundFetchEvent Экспериментальный
BackgroundFetchManager Экспериментальный
BackgroundFetchRecord Экспериментальный
BackgroundFetchRegistration Экспериментальный
BackgroundFetchUpdateUIEvent Экспериментальный
BarcodeDetector Экспериментальный
BarProp
BaseAudioContext
BatteryManager
BeforeInstallPromptEvent Экспериментальный Нестандартный
BeforeUnloadEvent
BiquadFilterNode
Blob
BlobEvent
Bluetooth Экспериментальный
BluetoothCharacteristicProperties Экспериментальный
BluetoothDevice Экспериментальный
BluetoothRemoteGATTCharacteristic Экспериментальный
BluetoothRemoteGATTDescriptor Экспериментальный
BluetoothRemoteGATTServer Экспериментальный
BluetoothRemoteGATTService Экспериментальный
BluetoothUUID
BroadcastChannel
ByteLengthQueuingStrategy

C

Cache
CacheStorage
CanMakePaymentEvent Экспериментальный
CanvasCaptureMediaStreamTrack
CanvasGradient
CanvasPattern
CanvasRenderingContext2D
CaptureController Экспериментальный
CaretPosition Экспериментальный
CDATASection
ChannelMergerNode
ChannelSplitterNode
CharacterData
Client
Clients
Clipboard
ClipboardEvent
ClipboardItem
CloseEvent
Comment
CompositionEvent
CompressionStream
console
ConstantSourceNode
ContactAddress Экспериментальный
ContactsManager Экспериментальный
ContentIndex Экспериментальный
ContentIndexEvent Экспериментальный
ContentVisibilityAutoStateChangeEvent Экспериментальный
ConvolverNode
CookieChangeEvent Экспериментальный
CookieStore Экспериментальный
CookieStoreManager Экспериментальный
CountQueuingStrategy
Credential
CredentialsContainer
Crypto
CryptoKey
CryptoKeyPair
CSPViolationReportBody
CSS
CSSAnimation
CSSConditionRule
CSSContainerRule
CSSCounterStyleRule
CSSFontFaceRule
CSSFontFeatureValuesRule
CSSFontPaletteValuesRule
CSSGroupingRule
CSSImageValue
CSSImportRule
CSSKeyframeRule
CSSKeyframesRule
CSSKeywordValue
CSSLayerBlockRule
CSSLayerStatementRule
CSSMathInvert
CSSMathMax
CSSMathMin
CSSMathNegate
CSSMathProduct
CSSMathSum
CSSMathValue
CSSMatrixComponent
CSSMediaRule
CSSNamespaceRule
CSSNumericArray
CSSNumericValue
CSSPageRule
CSSPerspective
CSSPositionValue Нестандартный Устаревший
CSSPrimitiveValue Устаревший
CSSPropertyRule
CSSPseudoElement Экспериментальный
CSSRotate
CSSRule
CSSRuleList
CSSScale
CSSSkew
CSSSkewX
CSSSkewY
CSSStyleDeclaration
CSSStyleRule
CSSStyleSheet
CSSStyleValue
CSSSupportsRule
CSSTransformComponent
CSSTransformValue
CSSTransition
CSSTranslate
CSSUnitValue
CSSUnparsedValue
CSSValue Устаревший
CSSValueList Устаревший
CSSVariableReferenceValue
CustomElementRegistry
CustomEvent
CustomStateSet Экспериментальный

D

DataTransfer
DataTransferItem
DataTransferItemList
DecompressionStream
DedicatedWorkerGlobalScope
DelayNode
DeprecationReportBody Экспериментальный
DeviceMotionEvent
DeviceMotionEventAcceleration
DeviceMotionEventRotationRate
DeviceOrientationEvent
DirectoryEntrySync Нестандартный Устаревший
DirectoryReaderSync Нестандартный Устаревший
Document
DocumentFragment
DocumentTimeline
DocumentType
DOMError Устаревший
DOMException
DOMHighResTimeStamp
DOMImplementation
DOMMatrix(ВебкитCSSMatrix)
DOMMatrixReadOnly
DOMParser
DOMPoint
DOMPointReadOnly
DOMQuad
DOMRect
DOMRectReadOnly
DOMStringList
DOMStringMap
DOMTokenList
DragEvent
DynamicsCompressorNode

E

EcdhKeyDeriveParams
EcdsaParams
EcKeyGenParams
EcKeyImportParams
Element
ElementInternals
EncodedAudioChunk Экспериментальный
EncodedVideoChunk
ErrorEvent
Event
EventCounts
EventSource
EventTarget
ExtendableCookieChangeEvent
ExtendableEvent
ExtendableMessageEvent
EyeDropper Экспериментальный

F

FeaturePolicy Экспериментальный
FederatedCredential Экспериментальный
FetchEvent
File
FileEntrySync Нестандартный Устаревший
FileList
FileReader
FileReaderSync
FileSystem
FileSystemDirectoryEntry
FileSystemDirectoryHandle
FileSystemDirectoryReader
FileSystemEntry
FileSystemFileEntry
FileSystemFileHandle
FileSystemHandle
FileSystemSync Нестандартный Устаревший
FileSystemSyncAccessHandle
FileSystemWritableFileStream
FocusEvent
FontData Экспериментальный
FontFace
FontFaceSet
FontFaceSetLoadEvent
FormData
FormDataEvent
FragmentDirective Экспериментальный

G

GainNode
Gamepad
GamepadButton
GamepadEvent
GamepadHapticActuator
GamepadPose Экспериментальный
Geolocation
GeolocationCoordinates
GeolocationPosition
GeolocationPositionError
GestureEvent Нестандартный
GPU Экспериментальный
GPUAdapter Экспериментальный
GPUAdapterInfo Экспериментальный
GPUBindGroup Экспериментальный
GPUBindGroupLayout Экспериментальный
GPUBuffer Экспериментальный
GPUCanvasContext Экспериментальный
GPUCommandBuffer Экспериментальный
GPUCommandEncoder Экспериментальный
GPUCompilationInfo Экспериментальный
GPUCompilationMessage Экспериментальный
GPUComputePassEncoder Экспериментальный
GPUComputePipeline Экспериментальный
GPUDevice Экспериментальный
GPUDeviceLostInfo Экспериментальный
GPUError Экспериментальный
GPUExternalTexture Экспериментальный
GPUInternalError Экспериментальный
GPUOutOfMemoryError Экспериментальный
GPUPipelineError Экспериментальный
GPUPipelineLayout Экспериментальный
GPUQuerySet Экспериментальный
GPUQueue Экспериментальный
GPURenderBundle Экспериментальный
GPURenderBundleEncoder Экспериментальный
GPURenderPassEncoder Экспериментальный
GPURenderPipeline Экспериментальный
GPUSampler Экспериментальный
GPUShaderModule Экспериментальный
GPUSupportedFeatures Экспериментальный
GPUSupportedLimits Экспериментальный
GPUTexture Экспериментальный
GPUTextureView Экспериментальный
GPUUncapturedErrorEvent Экспериментальный
GPUValidationError Экспериментальный
GravitySensor
Gyroscope

H

HashChangeEvent
Headers
HID Экспериментальный
HIDConnectionEvent Экспериментальный
HIDDevice Экспериментальный
HIDInputReportEvent Экспериментальный
Highlight Экспериментальный
HighlightRegistry Экспериментальный
History
HkdfParams
HmacImportParams
HmacKeyGenParams
HMDVRDevice Нестандартный Устаревший
HTMLAllCollection
HTMLAnchorElement
HTMLAreaElement
HTMLAudioElement
HTMLBaseElement
HTMLBodyElement
HTMLBRElement
HTMLButtonElement
HTMLCanvasElement
HTMLCollection
HTMLDataElement
HTMLDataListElement
HTMLDetailsElement
HTMLDialogElement
HTMLDivElement
HTMLDListElement
HTMLDocument
HTMLElement
HTMLEmbedElement
HTMLFieldSetElement
HTMLFontElement Устаревший
HTMLFormControlsCollection
HTMLFormElement
HTMLFrameSetElement Устаревший
HTMLHeadElement
HTMLHeadingElement
HTMLHRElement
HTMLHtmlElement
HTMLIFrameElement
HTMLImageElement
HTMLInputElement
HTMLLabelElement
HTMLLegendElement
HTMLLIElement
HTMLLinkElement
HTMLMapElement
HTMLMarqueeElement Устаревший
HTMLMediaElement
HTMLMenuElement
HTMLMenuItemElement Нестандартный Устаревший
HTMLMetaElement
HTMLMeterElement
HTMLModElement
HTMLObjectElement
HTMLOListElement
HTMLOptGroupElement
HTMLOptionElement
HTMLOptionsCollection
HTMLOutputElement
HTMLParagraphElement
HTMLParamElement Устаревший
HTMLPictureElement
HTMLPreElement
HTMLProgressElement
HTMLQuoteElement
HTMLScriptElement
HTMLSelectElement
HTMLSlotElement
HTMLSourceElement
HTMLSpanElement
HTMLStyleElement
HTMLTableCaptionElement
HTMLTableCellElement
HTMLTableColElement
HTMLTableElement
HTMLTableRowElement
HTMLTableSectionElement
HTMLTemplateElement
HTMLTextAreaElement
HTMLTimeElement
HTMLTitleElement
HTMLTrackElement
HTMLUListElement
HTMLUnknownElement
HTMLVideoElement

I

IDBCursor
IDBCursorWithValue
IDBDatabase
IDBFactory
IDBIndex
IDBKeyRange
IDBLocaleAwareKeyRange Экспериментальный Нестандартный
IDBObjectStore
IDBOpenDBRequest
IDBRequest
IDBTransaction
IDBVersionChangeEvent
IdentityCredential Экспериментальный
IdleDeadline
IdleDetector Экспериментальный
IIRFilterNode
ImageBitmap
ImageBitmapRenderingContext
ImageCapture Экспериментальный
ImageData
ImageDecoder Экспериментальный
ImageTrack Экспериментальный
ImageTrackList Экспериментальный
Ink Экспериментальный
InkPresenter Экспериментальный
InputDeviceCapabilities Экспериментальный
InputDeviceInfo
InputEvent
InstallEvent Нестандартный Устаревший
IntersectionObserver
IntersectionObserverEntry
InterventionReportBody Экспериментальный

K

Keyboard Экспериментальный
KeyboardEvent
KeyboardLayoutMap Экспериментальный
KeyframeEffect

L

LargestContentfulPaint Экспериментальный
LaunchParams Экспериментальный
LaunchQueue Экспериментальный
LayoutShift Экспериментальный
LayoutShiftAttribution Экспериментальный
LinearAccelerationSensor
Location
Lock
LockManager

M

Magnetometer Экспериментальный
MathMLElement
MediaCapabilities
MediaDeviceInfo
MediaDevices
MediaElementAudioSourceNode
MediaEncryptedEvent
MediaError
MediaImage
MediaKeyMessageEvent
MediaKeys
MediaKeySession
MediaKeyStatusMap
MediaKeySystemAccess
MediaList
MediaMetadata
MediaQueryList
MediaQueryListEvent
MediaRecorder
MediaRecorderErrorEvent Нестандартный Устаревший
MediaSession
MediaSource
MediaSourceHandle Экспериментальный
MediaStream
MediaStreamAudioDestinationNode
MediaStreamAudioSourceNode
MediaStreamEvent Нестандартный Устаревший
MediaStreamTrack
MediaStreamTrackAudioSourceNode
MediaStreamTrackEvent
MediaStreamTrackGenerator Экспериментальный Нестандартный
MediaStreamTrackProcessor Экспериментальный
MediaTrackConstraints
MediaTrackSettings
MediaTrackSupportedConstraints
MerchantValidationEvent Устаревший
MessageChannel
MessageEvent
MessagePort
Metadata Экспериментальный Нестандартный
MIDIAccess
MIDIConnectionEvent
MIDIInput
MIDIInputMap
MIDIMessageEvent
MIDIOutput
MIDIOutputMap
MIDIPort
MimeType Устаревший
MimeTypeArray Устаревший
MouseEvent
MouseScrollEvent Нестандартный Устаревший
MutationEvent Устаревший
MutationObserver
MutationRecord

N

NamedNodeMap
NavigateEvent Экспериментальный
Navigation Экспериментальный
NavigationCurrentEntryChangeEvent Экспериментальный
NavigationDestination Экспериментальный
NavigationHistoryEntry Экспериментальный
NavigationPreloadManager
NavigationTransition Экспериментальный
Navigator
NavigatorUAData Экспериментальный
NDEFMessage Экспериментальный
NDEFReader Экспериментальный
NDEFReadingEvent Экспериментальный
NDEFRecord Экспериментальный
NetworkInformation Экспериментальный
Node
NodeIterator
NodeList
Notification
NotificationEvent
NotifyAudioAvailableEvent Нестандартный Устаревший

O

OES_draw_buffers_indexed
OfflineAudioCompletionEvent
OfflineAudioContext
OffscreenCanvas
OffscreenCanvasRenderingContext2D
OrientationSensor
OscillatorNode
OTPCredential Экспериментальный
OverconstrainedError

P

PageTransitionEvent
PaintWorkletGlobalScope Экспериментальный
PannerNode
PasswordCredential Экспериментальный
Path2D
PaymentAddress Нестандартный Устаревший
PaymentManager Экспериментальный
PaymentMethodChangeEvent
PaymentRequest
PaymentRequestEvent Экспериментальный
PaymentRequestUpdateEvent
PaymentResponse
Pbkdf2Params
Performance
PerformanceElementTiming Экспериментальный
PerformanceEntry
PerformanceEventTiming
PerformanceLongTaskTiming Экспериментальный
PerformanceMark
PerformanceMeasure
PerformanceNavigation Устаревший
PerformanceNavigationTiming
PerformanceObserver
PerformanceObserverEntryList
PerformancePaintTiming
PerformanceResourceTiming
PerformanceServerTiming
PerformanceTiming Устаревший
PeriodicSyncEvent Экспериментальный
PeriodicSyncManager Экспериментальный
PeriodicWave
Permissions
PermissionStatus
PictureInPictureEvent
PictureInPictureWindow
Plugin Устаревший
PluginArray Устаревший
Point Нестандартный Устаревший
PointerEvent
PopStateEvent
PositionSensorVRDevice Нестандартный Устаревший
Presentation Экспериментальный
PresentationAvailability Экспериментальный
PresentationConnection Экспериментальный
PresentationConnectionAvailableEvent Экспериментальный
PresentationConnectionCloseEvent Экспериментальный
PresentationConnectionList Экспериментальный
PresentationReceiver Экспериментальный
PresentationRequest Экспериментальный
ProcessingInstruction
ProgressEvent
PromiseRejectionEvent
PublicKeyCredential
PushEvent
PushManager
PushMessageData
PushSubscription
PushSubscriptionOptions

R

RadioNodeList
Range
ReadableByteStreamController
ReadableStream
ReadableStreamBYOBReader
ReadableStreamBYOBRequest
ReadableStreamDefaultController
ReadableStreamDefaultReader
RelativeOrientationSensor
RemotePlayback
Report
ReportBody
ReportingObserver
Request
ResizeObserver
ResizeObserverEntry
ResizeObserverSize
Response
RsaHashedImportParams
RsaHashedKeyGenParams
RsaOaepParams
RsaPssParams
RTCAudioSourceStats
RTCCertificate
RTCDataChannel
RTCDataChannelEvent
RTCDtlsTransport
RTCDTMFSender
RTCDTMFToneChangeEvent
RTCError
RTCErrorEvent
RTCIceCandidate
RTCIceCandidatePair
RTCIceCandidatePairStats
RTCIceCandidateStats
RTCIceParameters
RTCIceServer
RTCIceTransport
RTCIdentityAssertion Экспериментальный
RTCInboundRtpStreamStats
RTCOutboundRtpStreamStats
RTCPeerConnection
RTCPeerConnectionIceErrorEvent
RTCPeerConnectionIceEvent
RTCPeerConnectionStats
RTCRemoteOutboundRtpStreamStats
RTCRtpCodecParameters
RTCRtpContributingSource
RTCRtpEncodingParameters
RTCRtpReceiver
RTCRtpSender
RTCRtpStreamStats
RTCRtpTransceiver
RTCSctpTransport
RTCSessionDescription
RTCStatsReport
RTCTrackEvent

S

Sanitizer Экспериментальный
Scheduler
Scheduling Экспериментальный
Screen
ScreenOrientation
ScriptProcessorNode Устаревший
ScrollTimeline Экспериментальный
SecurityPolicyViolationEvent
Selection
Sensor
SensorErrorEvent
Serial Экспериментальный
SerialPort Экспериментальный
ServiceWorker
ServiceWorkerContainer
ServiceWorkerGlobalScope
ServiceWorkerRegistration
ShadowRoot
SharedWorker
SharedWorkerGlobalScope
SourceBuffer
SourceBufferList
SpeechGrammar Экспериментальный
SpeechGrammarList Экспериментальный
SpeechRecognition
SpeechRecognitionAlternative
SpeechRecognitionErrorEvent
SpeechRecognitionEvent
SpeechRecognitionResult
SpeechRecognitionResultList
SpeechSynthesis
SpeechSynthesisErrorEvent
SpeechSynthesisEvent
SpeechSynthesisUtterance
SpeechSynthesisVoice
StaticRange
StereoPannerNode
Storage
StorageEvent
StorageManager
StylePropertyMap
StylePropertyMapReadOnly
StyleSheet
StyleSheetList
SubmitEvent
SubtleCrypto
SVGAElement
SVGAngle
SVGAnimateColorElement Устаревший
SVGAnimatedAngle
SVGAnimatedBoolean
SVGAnimatedEnumeration
SVGAnimatedInteger
SVGAnimatedLength
SVGAnimatedLengthList
SVGAnimatedNumber
SVGAnimatedNumberList
SVGAnimatedPreserveAspectRatio
SVGAnimatedRect
SVGAnimatedString
SVGAnimatedTransformList
SVGAnimateElement
SVGAnimateMotionElement
SVGAnimateTransformElement
SVGAnimationElement
SVGCircleElement
SVGClipPathElement
SVGComponentTransferFunctionElement
SVGCursorElement Устаревший
SVGDefsElement
SVGDescElement
SVGElement
SVGEllipseElement
SVGEvent
SVGFEBlendElement
SVGFEColorMatrixElement
SVGFEComponentTransferElement
SVGFECompositeElement
SVGFEConvolveMatrixElement
SVGFEDiffuseLightingElement
SVGFEDisplacementMapElement
SVGFEDistantLightElement
SVGFEDropShadowElement
SVGFEFloodElement
SVGFEFuncAElement
SVGFEFuncBElement
SVGFEFuncGElement
SVGFEFuncRElement
SVGFEGaussianBlurElement
SVGFEImageElement
SVGFEMergeElement
SVGFEMergeNodeElement
SVGFEMorphologyElement
SVGFEOffsetElement
SVGFEPointLightElement
SVGFESpecularLightingElement
SVGFESpotLightElement
SVGFETileElement
SVGFETurbulenceElement
SVGFilterElement
SVGFontElement Устаревший
SVGFontFaceElement Устаревший
SVGFontFaceFormatElement Устаревший
SVGFontFaceNameElement Устаревший
SVGFontFaceSrcElement Устаревший
SVGFontFaceUriElement Устаревший
SVGForeignObjectElement
SVGGElement
SVGGeometryElement
SVGGlyphElement Устаревший
SVGGlyphRefElement Устаревший
SVGGradientElement
SVGGraphicsElement
SVGHKernElement Устаревший
SVGImageElement
SVGLength
SVGLengthList
SVGLinearGradientElement
SVGLineElement
SVGMarkerElement
SVGMaskElement
SVGMetadataElement
SVGMissingGlyphElement Устаревший
SVGMPathElement
SVGNumber
SVGNumberList
SVGPathElement
SVGPatternElement
SVGPoint Устаревший
SVGPointList
SVGPolygonElement
SVGPolylineElement
SVGPreserveAspectRatio
SVGRadialGradientElement
SVGRect
SVGRectElement
SVGRenderingIntent Устаревший
SVGScriptElement
SVGSetElement
SVGStopElement
SVGStringList
SVGStyleElement
SVGSVGElement
SVGSwitchElement
SVGSymbolElement
SVGTextContentElement
SVGTextElement
SVGTextPathElement
SVGTextPositioningElement
SVGTitleElement
SVGTransform
SVGTransformList
SVGTRefElement Устаревший
SVGTSpanElement
SVGUnitTypes
SVGUseElement
SVGViewElement
SVGVKernElement Устаревший
SyncEvent Экспериментальный
SyncManager Экспериментальный

T

TaskAttributionTiming Экспериментальный
TaskController
TaskPriorityChangeEvent
TaskSignal
Text
TextDecoder
TextDecoderStream
TextEncoder
TextEncoderStream
TextMetrics
TextTrack
TextTrackCue
TextTrackCueList
TextTrackList
TimeEvent
TimeRanges
ToggleEvent
Touch
TouchEvent
TouchList
TrackEvent
TransformStream
TransformStreamDefaultController
TransitionEvent
TreeWalker
TrustedHTML
TrustedScript
TrustedScriptURL
TrustedTypePolicy
TrustedTypePolicyFactory

U

UIEvent
URL
URLPattern Экспериментальный
URLSearchParams
USB Экспериментальный
USBAlternateInterface Экспериментальный
USBConfiguration Экспериментальный
USBConnectionEvent Экспериментальный
USBDevice Экспериментальный
USBEndpoint Экспериментальный
USBInterface Экспериментальный
USBInTransferResult Экспериментальный
USBIsochronousInTransferPacket Экспериментальный
USBIsochronousInTransferResult Экспериментальный
USBIsochronousOutTransferPacket Экспериментальный
USBIsochronousOutTransferResult Экспериментальный
USBOutTransferResult Экспериментальный
UserActivation

V

ValidityState
VideoColorSpace
VideoDecoder
VideoEncoder
VideoFrame
VideoPlaybackQuality
VideoTrack
VideoTrackList
ViewTimeline Экспериментальный
ViewTransition Экспериментальный
VirtualKeyboard Экспериментальный
VisibilityStateEntry Экспериментальный
VisualViewport
VRDisplay Нестандартный Устаревший
VRDisplayCapabilities Нестандартный Устаревший
VRDisplayEvent Нестандартный Устаревший
VREyeParameters Нестандартный Устаревший
VRFieldOfView Нестандартный Устаревший
VRFrameData Нестандартный Устаревший
VRLayerInit Устаревший
VRPose Нестандартный Устаревший
VRStageParameters Нестандартный Устаревший
VTTCue
VTTRegion

W

WakeLock
WakeLockSentinel
WaveShaperNode
WebGL2RenderingContext
WebGLActiveInfo
WebGLBuffer
WebGLContextEvent
WebGLFramebuffer
WebGLObject
WebGLProgram
WebGLQuery
WebGLRenderbuffer
WebGLRenderingContext
WebGLSampler
WebGLShader
WebGLShaderPrecisionFormat
WebGLSync
WebGLTexture
WebGLTransformFeedback
WebGLUniformLocation
WebGLVertexArrayObject
WebSocket
WebTransport
WebTransportBidirectionalStream
WebTransportDatagramDuplexStream
WebTransportError
WebTransportReceiveStream Экспериментальный
WGSLLanguageFeatures Экспериментальный
WheelEvent
Window
WindowClient
WindowControlsOverlay Экспериментальный
WindowControlsOverlayGeometryChangeEvent Экспериментальный
Worker
WorkerGlobalScope
WorkerLocation
WorkerNavigator
Worklet
WorkletGlobalScope
WritableStream
WritableStreamDefaultController
WritableStreamDefaultWriter

X

XMLDocument
XMLHttpRequest
XMLHttpRequestEventTarget
XMLHttpRequestUpload
XMLSerializer
XPathEvaluator
XPathException
XPathExpression
XPathNSResolver
XPathResult
XRAnchor Экспериментальный
XRAnchorSet Экспериментальный
XRBoundedReferenceSpace Экспериментальный
XRCompositionLayer Экспериментальный
XRCPUDepthInformation Экспериментальный
XRCubeLayer Экспериментальный
XRCylinderLayer Экспериментальный
XRDepthInformation Экспериментальный
XREquirectLayer Экспериментальный
XRFrame Экспериментальный
XRHand
XRHitTestResult Экспериментальный
XRHitTestSource Экспериментальный
XRInputSource
XRInputSourceArray Экспериментальный
XRInputSourceEvent
XRInputSourcesChangeEvent
XRJointPose
XRJointSpace
XRLayer Экспериментальный
XRLayerEvent Экспериментальный
XRLightEstimate Экспериментальный
XRLightProbe Экспериментальный
XRMediaBinding Экспериментальный
XRPose
XRProjectionLayer Экспериментальный
XRQuadLayer Экспериментальный
XRRay Экспериментальный
XRReferenceSpace
XRReferenceSpaceEvent
XRRenderState Экспериментальный
XRRigidTransform
XRSession Экспериментальный
XRSessionEvent
XRSpace
XRSubImage Экспериментальный
XRSystem Экспериментальный
XRTransientInputHitTestResult Экспериментальный
XRTransientInputHitTestSource Экспериментальный
XRView Экспериментальный
XRViewerPose
XRViewport
XRWebGLBinding Экспериментальный
XRWebGLDepthInformation Экспериментальный
XRWebGLLayer Экспериментальный
XRWebGLSubImage Экспериментальный
XSLTProcessor

Дополнения и Файлы

Ссылка на оригинальную статью

canvas_api

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Aug 2023 18:03:19 +0000

Canvas API

Canvas API (Холст API) предоставляет средства для рисования графики с помощью JavaScript и элемента HTML <canvas> . Помимо прочего, его можно использовать для анимации, игровой графики, визуализации данных, манипулирования фотографиями и обработки видео в реальном времени.

Canvas API в основном ориентирован на 2D-графику. API WebGL , который также использует этот <canvas>элемент, рисует 2D- и 3D-графику с аппаратным ускорением.

Базовый пример Этот простой пример рисует зеленый прямоугольник на холсте.

HTML HTML Играть Скопировать в буфер обмена

<canvas id=«canvas»></canvas> JavaScript Метод Document.getElementById()получает ссылку на <canvas>элемент HTML. Затем HTMLCanvasElement.getContext()метод получает контекст этого элемента — объект, на котором будет отображаться рисунок.

Фактический рисунок выполняется с использованием CanvasRenderingContext2Dинтерфейса. Свойство fillStyleделает прямоугольник зеленым. Метод fillRect()помещает верхний левый угол в точку (10, 10) и присваивает ему размер 150 единиц в ширину и 100 в высоту.

JS Играть Скопировать в буфер обмена

const canvas = document.getElementById(«canvas»); const ctx = canvas.getContext(«2d»);

ctx.fillStyle = «green»; ctx.fillRect(10, 10, 150, 100); Результат Играть

Ссылка HTMLCanvasElement CanvasRenderingContext2D CanvasGradient CanvasPattern ImageBitmap ImageData TextMetrics OffscreenCanvas Path2D Экспериментальный ImageBitmapRenderingContext Экспериментальный Примечание. Интерфейсы, связанные с ними WebGLRenderingContext, указаны в разделе WebGL .

Примечание: OffscreenCanvas также доступно в веб-воркерах.

CanvasCaptureMediaStreamTrackэто связанный интерфейс.

Руководства и учебные пособия Учебное пособие по холсту Подробное руководство, охватывающее как базовое использование Canvas API, так и его расширенные функции.

Глубокое погружение в HTML5 Canvas Практическое введение в Canvas API и WebGL длиной в книгу.

Справочник по холсту Удобный справочник по Canvas API.

Манипулирование видео с помощью холста Объединение <video>и <canvas>манипулирование видеоданными в реальном времени.

Библиотеки Canvas API чрезвычайно мощный, но не всегда простой в использовании. Перечисленные ниже библиотеки могут ускорить и упростить создание проектов на основе холста.

EaselJS — это библиотека холстов с открытым исходным кодом, которая упрощает создание игр, генеративного искусства и других высокографических задач. Fabric.js — это библиотека холстов с открытым исходным кодом и возможностями анализа SVG. Heatmap.js — это библиотека с открытым исходным кодом для создания тепловых карт данных на основе холста. JavaScript InfoVis Toolkit создает интерактивную визуализацию данных. Konva.js — это библиотека 2D-холста для настольных и мобильных приложений. p5.js имеет полный набор функций рисования на холсте для художников, дизайнеров, преподавателей и новичков. Paper.js — это среда разработки сценариев векторной графики с открытым исходным кодом, работающая поверх HTML Canvas. Phaser — это быстрая, бесплатная и увлекательная платформа с открытым исходным кодом для браузерных игр на основе Canvas и WebGL. Pts.js — это библиотека для творческого кодирования и визуализации в Canvas и SVG. Rekapi — это API создания ключевых кадров анимации для Canvas. Scrawl-canvas — это библиотека JavaScript с открытым исходным кодом для создания и управления 2D-элементами холста. Платформа ZIM предоставляет удобства, компоненты и элементы управления для творческого кодирования на холсте, включая специальные возможности и сотни красочных руководств. Sprig — это удобная для начинающих библиотека разработки игр на основе плиток с открытым исходным кодом, использующая Canvas. Примечание. См. API WebGL для 2D- и 3D-библиотек, использующих WebGL.

mediastream

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Aug 2023 16:59:06 +0000

Медиапоток

Интерфейс MediaStreamпредставляет собой поток медиаконтента. Поток состоит из нескольких дорожек , например видео- или аудиодорожек. Каждая дорожка указывается как экземпляр MediaStreamTrack.

Вы можете получить MediaStreamобъект либо с помощью конструктора, либо путем вызова таких функций, как MediaDevices.getUserMedia(), MediaDevices.getDisplayMedia()или HTMLCanvasElement.captureStream().

Некоторые пользовательские агенты подклассифицируют этот интерфейс для предоставления более точной информации или функций, как в CanvasCaptureMediaStreamTrack.

EventTarget MediaStream Конструктор MediaStream() Создает и возвращает новый MediaStreamобъект. Вы можете создать пустой поток, поток, основанный на существующем потоке, или поток, содержащий указанный список дорожек (заданный как массив объектов MediaStreamTrack).

Свойства экземпляра Этот интерфейс наследует свойства своего родителя, EventTarget.

MediaStream.active Только чтение Логическое значение, которое возвращается , trueесли MediaStreamактивен или falseнет.

MediaStream.id Только чтение Строка, содержащая 36-значный универсальный уникальный идентификатор ( UUID ) объекта.

Методы экземпляра Этот интерфейс наследует методы от своего родителя, EventTarget.

MediaStream.addTrack() Сохраняет копию данного параметра MediaStreamTrackв качестве аргумента. Если трек уже добавлен к объекту MediaStream, ничего не происходит.

MediaStream.clone() Возвращает клон объекта MediaStream. Однако клон будет иметь уникальное значение для id.

MediaStream.getAudioTracks() Возвращает список объектов, MediaStreamTrackхранящихся в MediaStreamобъекте, для которых kindустановлен атрибут audio. Порядок не определен и может меняться не только от одного браузера к другому, но и от одного вызова к другому.

MediaStream.getTrackById() Возвращает трек, идентификатор которого соответствует указанному в параметрах trackid. Если параметр не указан или трек с таким идентификатором не существует, возвращается null. Если несколько треков имеют одинаковый идентификатор, возвращается первый.

MediaStream.getTracks() Возвращает список всех MediaStreamTrackобъектов, хранящихся в MediaStreamобъекте, независимо от значения атрибута kind. Порядок не определен и может меняться не только от одного браузера к другому, но и от одного вызова к другому.

MediaStream.getVideoTracks() Возвращает список объектов, MediaStreamTrackхранящихся в MediaStreamобъекте, для которых kindустановлен атрибут «video». Порядок не определен и может меняться не только от одного браузера к другому, но и от одного вызова к другому.

MediaStream.removeTrack() Удаляет MediaStreamTrackданное в качестве аргумента. Если дорожка не является частью объекта MediaStream, ничего не происходит.

События addtrack MediaStreamTrackВызывается при добавлении нового объекта.

removetrack Вызывается, когда MediaStreamTrackобъект был удален.

active Запускается при активации MediaStream.

inactive Запускается, когда MediaStream деактивируется.

rest_api

anonymous@undisclosed.example.com (Anonymous) — Mon, 13 Oct 2025 11:54:08 +0000

Руководство по REST API

Что такое REST?

Архитектура REST описывается шестью ограничениями. Эти ограничения, применительно к архитектуре, первоначально были представлены Роем Филдингом (Roy Fielding) в его докторской диссертации и определяют основы RESTful стиля.

Шесть ограничений:

Единый интерфейс определяет интерфейс между клиентами и серверами. Это упрощает и отделяет архитектуру, которая позволяет каждой части развиваться самостоятельно. Четыре принципа единого интерфейса:

Основан на ресурсах
Отдельные ресурсы определяются в запросе, для чего используется URI, как идентификаторы ресурсов. Сами ресурсы концептуально отделены от представлений, которые возвращаются клиенту. Например, сервер не отправляет свою базу данных, а, скорее, некоторые HTML, XML или JSON, которые представляет некоторые записи в базе данных, например, на финском языке и в UTF-8, в зависимости от деталей запроса и реализации сервера.

Манипуляции над ресурсами через представления
Когда пользователь имеет представление о ресурсе, в том числе о связанных метаданных, он имеет достаточно информации для изменения или удаления ресурса на сервере, если у него есть на это разрешение

Самодокументируемые сообщения
Каждое сообщение содержит достаточно информации для описания того, как его выполнить. Например, вызываемый парсер может описываться с помощью Internet media type (так же известным как MIME) Ответы также явно указывают на их способность кешировать.

Hypermedia as the Engine of Application State (HATEOAS)
Клиенты предоставляют статус через содержимое body, параметры строки запроса, заголовки запросов и запрашиваемый URI (имя ресурса). Это называется гипермедиа (или гиперссылки с гипертекстом)

Наряду с приведенным выше описанием, HATEOAS также означает, что, в случае необходимости ссылки содержатся в теле ответа (или заголовках) для поддержки URI извлечения самого объекта или запрошенных объектов. Позднее, мы затронем эту тему глубже.

Единый интерфейс так же означает, что любой REST сервис должен обеспечивать его фундаментальный дизайн.

Так как REST это акроним для REpresentational State Transfer, отсутствие состояний является важной чертой. Таким образом, это значит, что необходимое состояние для обработки запроса содержится в самом запросе, либо в рамках URI, параметрах строки запроса, тела или заголовках. URI уникально идентифицирует ресурс, и тело содержит состояние (или изменение состояния) этого ресурса. Затем, после того, как сервер завершит обработку, состояние или его часть(и) отдаётся обратно клиенту через заголовки, статус и тело ответа.

Большинство из нас, кто был в этой отрасли, привыкли к программированию в контейнере, который даёт нам понятие «Сессия, которая поддерживает состояние нескольких HTTP запросов. В REST, клиент должен включать всю информацию для сервера для выполнения запроса, по необходимости повторно отправляя состояние, если это состояние должно охватывать несколько запросов. Отсутствие состояний обеспечивает большую масштабируемость, так как сервер не должен поддерживать или общаться через состояние сеанса. Кроме того, балансировщику нагрузки не придётся беспокоиться о связанности сессии и системы.

Так в чём различие между состоянием и ресурсом? Состояние или состояние приложения, это то, что сервер заботится выполнить запрос для получения данных необходимых для текущей сессии или запроса. Ресурсное состояние, или ресурс, это данные, которые определяют представление ресурса, например, данные хранящиеся в базе данных. Рассмотрим состояние приложения как данные, которые могут варьироваться в зависимости от клиента и запроса. С другой стороны, состояние ресурсов постоянно по каждому клиенту, который запрашивает его.

Каждый встречал проблему с кнопкой «Назад» в своём веб приложении, когда оно ведет себя по-разному в одной точке, потому что ожидались действия в определенном порядке? Такое происходит, когда нарушен принцип отсутствия состояний. Есть случаи, когда не соблюдается принцип отсутствия состояний, например, three-legged OAuth, ограничение скорости вызова API и т.д. Однако, приложите максимум усилий, чтобы состояние приложения не занимало несколько запросов к вашему сервису.

Как и в World Wide Web, клиент может кэшировать ответы. Таким образом, ответы явно или неявно определяют себя как кешируемые или нет, для предотвращения повторного использования клиентами устаревших или некорректных данных в ответ на дальнейшие запросы. Хорошо спроектированное кэширование частично или полностью устраняет некоторые клиент-серверные взаимодействия, способствуя дальнейшей масштабируемости и производительности.

Единый интерфейс отделяет клиентов от серверов. Разделение интерфейсов означает, что, например, клиенты не связаны с хранением данных, которое остаётся внутри каждого сервера, так что мобильность кода клиента улучшается. Серверы не связаны с интерфейсом пользователя или состоянием, так что серверы могут быть проще и масштабируемы. Серверы и клиенты могут быть заменяемы и разрабатываться независимо, пока интерфейс не изменяется.

Обычно клиенты не могу сказать — они подключены напрямую к серверу или общаются через посредника. Промежуточный сервер может улучшить масштабируемость системы, обеспечивая балансировку нагрузки и предоставляя общий кэш. Слои также могут отвечать за политику безопасности.

Серверы могут временно расширять или настраивать функциональность клиента, передавая ему логику, которую он может исполнять. Например, это могут быть скомпилированные Java-апплеты или клиентские скрипты на Javascript

Соблюдая эти ограничения, и, таким образом, придерживаясь RESTful архитектуры, мы позволяем распределенной системе любого типа иметь такие свойства как: производительность, расширяемость, простота, обновляемость, понятность, портативность и надёжность.

Замечание Единственным необязательным ограничением для RESTful архитектуры — это «код по требованию». Если сервис не проходит по любым другим условиям, то его совершенно точно нельзя назвать RESTful.

Советы по REST API

Будь то RESTful или нет (в соответствии с шестью ограничениями, описанными ранее), вот несколько рекомендованных REST концепций, которые помогут построить более хорошие и удобные сервисы:

Используйте HTTP-глаголы, чтобы ваши запросы имели понятное значение

Пользователи API должны иметь возможность отправлять команды GET, POST, PUT и DELETE, что значительно повышает ясность того, что делает запрос.

Как правило, четыре основных HTTP-глагола используются следующим образом:

GET

Прочитать конкретный ресурс (по идентификатору) или набор ресурсов

PUT

Обновить конкретный ресурс (по идентификатору) или набор ресурсов. Также может использоваться для создания определенного ресурса, если идентификатор ресурса известен заранее

DELETE

Удалить конкретный ресурс по идентификатору

POST

Создать новый ресурс. Также универсальное действие для операций, которые не вписываются в другие категории

Примечание

GET-запросы не должны изменять данные базовых ресурсов. При этом может выполняться отслеживание, приводящее к обновлению данных, но данные ресурса, идентифицированного данным URI, не должны изменяться.

Давайте ресурсам продуманные имена

Создание хорошего API — это на 80% искусство и на 20% наука. Создание иерархии осмысленных URL-адресов относится к искусству. Рациональное наименование ресурсов (названия которых представляют собой просто URL-пути, такие как /customers/12345/orders) улучшает понимание того, что делает данный запрос.

Подходящие названия ресурсов предоставляют контекст для запроса и делают API сервиса более понятным. Ресурсы должны просматриваться иерархически по их именам. Пользователям должна предлагаться удобная, легко понимаемая иерархия ресурсов для использования в их приложениях.

Вот несколько простых правил для дизайна URL-пути (имени ресурса):

Используйте идентификаторы в URL-адресах, а не в строке запроса. Использование параметров строки запроса отлично подходит для фильтрации, но не для имен ресурсов
- Хорошо: /users/12345
- Плохо: /api?type=user&id=23

URL-адреса иерархичны, пользуйтесь этим для задания структуры ресурсов

Дизайн сервиса должен быть ориентирован на ваших клиентов, а не на ваши данные

Имена ресурсов должны быть существительными. Избегайте глаголов в именах ресурсов, это позволит сделать их яснее. Используйте методы HTTP, чтобы указать, какое действие выполняет запрос

Используйте множественное число в соответствующих сегментах URL-адресов, чтобы обеспечить согласованность URI вашего API во всех HTTP-методах, применяя метафору коллекции
- Хорошо: /customers/33245/orders/8769/lineitems/1
- Плохо: /customer/33245/order/8769/lineitem/1

Избегайте использования наборов слов в URL-адресах (например, customer_list в качестве ресурса). Используйте множественное число для названий коллекций
- Хорошо: /customers
- Плохо: /customer_list

Используйте строчные буквы в URL, разделяя слова подчеркиванием («_») или дефисом (»-«). Некоторые серверы игнорируют регистр, поэтому лучше четко придерживаться нижнего регистра

Старайтесь, чтобы URL-адреса были как можно короче и содержали как можно меньше сегментов

Используйте коды HTTP-ответов для указания статуса

Коды ответа являются частью спецификации HTTP. Для описания самых распространенных ситуаций существует большой набор HTTP-ответов.

Поскольку наши RESTful сервисы следуют спецификации HTTP, наши веб-API должны возвращать коды состояний HTTP. Например, когда ресурс успешно создан с помощью запроса POST, API должен вернуть код состояния HTTP 201. Полный список возможных кодов состояния HTTP c подробным описанием доступен здесь

Top 10 кодов состояния HTTP-ответа:

200 ОК

Код, указывающий на успешное выполнение запроса и чаще всего встречающийся на практике

201 CREATED

Ресурс успешно создан (через POST или PUT). Установите заголовок Location со ссылкой на вновь созданный ресурс (при POST). Тело ответа может быть как пустым, так и содержать что-то 204 NO CONTENT Запрос выполнен успешно, но в теле ответа нет данных. Часто используется для операций DELETE и PUT

400 BAD REQUEST

Общая ошибка, когда при выполнении запроса возникает недопустимое состояние. Примеры - ошибки проверки домена, отсутствующие данные и т.д.

401 UNAUTHORIZED

Код ошибки для отсутствующего или недопустимого токена аутентификации

403 FORBIDDEN

Код ошибки, когда пользователь не авторизован для выполнения операции или ресурс недоступен по какой-либо причине (например, ограничения по времени и т.п.)

404 NOT FOUND

Этот код используется, когда запрошенный ресурс не найден. Ресурс не существует, либо была ошибка 401 или 403, которую по соображениям безопасности сервис хочет скрыть

405 METHOD NOT ALLOWED

Используется для указания на то, что запрошенный URL-адрес существует, но используемый HTTP-метод неприменим. Например, POST /users/12345, где API не поддерживает создание ресурсов таким образом (с предоставленным идентификатором). При возврате ошибки 405 должен быть установлен HTTP-заголовок Allow, указывающий на поддерживаемые методы HTTP. В примере выше заголовок выглядел бы как “Allow: GET, PUT, DELETE”

409 CONFLICT

Этот код ошибки отправляется всякий раз, когда выполнение запроса может привести к конфликту ресурсов. Примеры таких ситуаций - двойные записи, например, попытка создать двух клиентов с одинаковой информацией; удаление корневых объектов, когда не поддерживается каскадное удаление

500 INTERNAL SERVER ERROR

Никогда не отправляйте этот код вручную. Это общая ошибка, когда на стороне сервера выбрасывается какое-то исключение. Этот код должен использоваться только для ошибок, которые пользователь не может устранить со своей стороны

XML и JSON

Если вы не работаете в строго стандартизированной и регулируемой отрасли, лучше поддерживать JSON. Но если вас ничто не сковывает, позвольте пользователям выбирать в каком формате получать данные — JSON или XML. У пользователей должна быть возможность переключаться между ними с помощью HTTP-заголовка Accept или просто изменив расширение с .xml на .json.

Имейте в виду, что как только мы начинаем говорить о поддержке XML, мы начинаем говорить о валидации, пространствах имен и т.д. Если этого не требует ваша отрасль, избегайте поддержки всех этих усложнений. По крайней мере, вначале. А если в этом функционале нет острой необходимости, то всегда. JSON является простым, лаконичным и функциональным. Сделайте так, чтобы ваш XML выглядел так же, если это возможно.

Другими словами, сделайте возвращаемый XML более похожим на JSON — простым и легко читаемым, без сведений о схеме и пространстве имен, содержащим только данные и ссылки. Если ваш XML будет более сложным, стоимость поддержки будет неоправданно большой. Если судить по нашему опыту — никто никогда не отвечает в формате XML. Обрабатывать XML слишком затратно.

Обратите внимание, что JSON-Schema предлагает возможности по валидации XML, если вам все-таки нужен такой функционал.

Создавайте детальные ресурсы

Сначала гораздо проще создавать API, которые имитируют основной домен приложения или архитектуру базы данных вашей системы. В конце концов, вы захотите объединить сервисы, которые используют несколько основных ресурсов, чтобы избежать избыточности информации. Позже будет гораздо проще создать большие ресурсы из отдельных ресурсов, чем детальные ресурсы из более крупных составных ресурсов. Упростите себе задачу и начните с небольших, легко определяемых ресурсов, предоставив для них CRUD-функциональность. Ресурсы без лишней информации, ориентированные на конкретные ситуации, можно сделать позже.

Учитывайте связность

Одним из принципов REST является связность через ссылки. Хотя сервисы остаются полезными и без них, API становится более самоописательным, когда в ответе содержатся ссылки. По крайней мере, ссылка “на себя” информирует клиентов, как данные были или могут быть получены. Кроме того, используйте заголовок Location, который должен содержать ссылку на создание ресурса с помощью POST (или PUT). Для коллекций возвращайте в ответе сведения о том, что поддерживается пагинация, а также, как минимум, ссылки “первая”, “последняя”, “следующая” и “предыдущая”.

Что касается форматов ссылок, то их существует довольно много.

Спецификация HTTP веб-ссылок RFC5988 определяет ссылку следующим образом:

Ссылка — это типизированное соединение между двумя ресурсами, идентифицируемыми интернационализированными идентификаторами ресурсов (IRI) [RFC3987]

Ссылка состоит из:

контекстного IRI
типа ссылки
целевого IRI
целевых атрибутов (опционально)

Ссылку можно рассматривать как утверждение вида {контекстный IRI} имеет ресурс {типа} в {целевом IRI}, который имеет {целевые атрибуты}.

По меньшей мере, размещайте ссылки в HTTP-заголовке Link, как это рекомендовано в спецификации, или используйте JSON-представление данного стиля HTTP-ссылок (например, ссылки в стиле Atom, см. RFC4287). По мере того, как ваш API будет становиться более зрелым, вы сможете использовать более сложные стили ссылок, такие как HAL+JSON, Siren, Collection+JSON и/или JSON-LD и т.д.

Именование ресурсов

Кроме правильного использования HTTP глаголов, именование ресурсов, вероятно, самая обсуждаемая и важная концепция для понимания во время создания понятного и легко используемого API для Web-сервиса. Когда ресурсы названы хорошо, API интуитивен и лёгок в использовании. Если же ресурсы названы плохо, тот же самый API может показаться неуклюжим и трудным в понимании и использовании. Ниже приведены несколько подсказок, как продолжить создавать URI ресурсов для нового API.

Фактически RESTful API - это всего лишь набор URI, HTTP вызовов к этим URI и некоторое количество представлений ресурсов в формате JSON и/или XML, многие из которых будут содержать перекрестные ссылки. За основу адресации берется покрытие уникальными идентификаторами ресурсов (URI) У каждого ресурса есть свой адрес или URI: вся интересная информация, которую сервер может предоставить, представлена как ресурс. Ограничение однообразия интерфейса частично реализовано с помощью комбинаций URI и HTTP глаголов и их использованием в соответствии со стандартами и конвенциями.

Когда вы решаете, какие ресурсы будут в вашей системе, называйте их существительными, в противоположность глаголам, или действиям. Другими словами, URI должен ссылаться на ресурс, а не на действие. Ещё один отличающий фактор - у существительных есть такие свойства, которых нет у глаголов.

Ниже приведены примеры ресурсов:

Пользователи системы.
Курсы, в которых зарегистрирован студент.
История сообщений пользователя.
Пользователь, который подписан на другого пользователя.
Пользователи, которые подписаны на другого пользователя.
Статья о верховой езде.

Каждый ресурс сервиса должен иметь хотя бы один URI, идентифицирующий его. И лучше всего, когда этот URI имеет смысл и адекватно описывает этот ресурс. URI должны иметь предсказуемую, иерархическую структуру, чтобы увеличить понятность и, как следствие, юзабилити: предсказуемость означает, что они консистентны, иерархичность означает, что у данных есть структура взаимоотношений. Это не принцип и не ограничение REST, но это улучшает API.

RESTful API пишут для потребителей. Названия и структура URI должна передавать смысл этим потребителям. Очень часто трудно понять, где должны быть границы, но с пониманием ваших данных вы поймете и то, что имеет смысл возвращать как представление вашим клиентам. Проектируйте для клиентов, а не для ваших данных.

Давайте предположим, что мы описываем систему с покупателями, заказами, отдельными позициями, продуктами и т. д. Рассмотрим URI, включенные в описание ресурсов этого сервиса:

Примеры

Чтобы создать нового покупателя в системе мы используем:

POST http://www.example.com/customers

Чтобы получить информацию о покупателе с ID# 33245:

GET http://www.example.com/customers/33245 Тот же URI мы используем для PUT и DELETE, чтобы обновлять и удалять, соответственно.

Ниже предложены URI для продуктов:

POST http://www.example.com/products для создания нового продукта.

GET|PUT|DELETE http://www.example.com/products/66432
для чтения, обновления, удаления продукта с ID# 66432, соответственно.

Теперь становится весело… Как насчёт создания нового заказа у покупателя? Один вариант - POST http://www.example.com/orders. Это может работать для создания заказа, но здесь, пожалуй, не учитывается покупатель.

Поскольку мы хотим создать заказ для покупателя, (заметьте связь), этот URI, очевидно, не так интуитивен, как мог бы быть. Очевидно, что следующий URI предлагает большую ясность: POST http://www.example.com/customers/33245/orders Теперь мы знаем, что создаём заказ для покупателя с ID# 33245.

Что же вернет следующее?

GET http://www.example.com/customers/33245/orders
Вероятно, список заказов покупателя #33245. Заметьте: мы можем не поддерживать DELETE или PUT для этого URL, поскольку он оперирует коллекцией.

Теперь, продолжая концепцию иерархичности, как насчёт следующего URI?

POST http://www.example.com/customers/33245/orders/8769/lineitems
Это может добавлять отдельную позицию в заказ #8769 (который принадлежит покупателю #33245). Точно! GET на этот URI вернет все отдельные позиции данного заказа. Как бы то ни было, если отдельные позиции нельзя рассматривать только в контексте покупателя, или их можно рассматривать вне его контекста, мы можем предложить POST www.example.com/orders/8769/lineitems.

Наряду с этими строками, поскольку может быть несколько URI для заданного ресурса, мы также можем предложить GET http://www.example.com/orders/8769, который возвращает информацию о заказе по его ID без указания ID покупателя

Спускаясь глубже по иерархии:

GET http://www.example.com/customers/33245/orders/8769/lineitems/1
Может возвращать только первую отдельную позицию в заказе.

К этому моменту вы уже можете видеть, как работает концепция иерархичности. Нет никаких жёстких правил, убедитесь только, что предложенная структура понятна потребителю ваших сервисов. Как и все в ремесле разработки ПО, именование критично для успеха.

Взгляните на некоторые широко используемые API, чтобы приобрести навык проектирования и используйте интуицию своих коллег, чтобы улучшить URI ресурсов вашего API. Ниже приведены некоторые примеры API:

* Twitter: https://dev.twitter.com/docs/api
* Facebook: http://developers.facebook.com/docs/reference/api/
* LinkedIn: https://developer.linkedin.com/apis

Пока мы обсуждали некоторые примеры подходящих названий для ресурсов, иногда более информативно увидеть некоторые анти-паттерны. Ниже представлены плохие примеры RESTful URI ресурсов, которые были замечены в "дикой природе." Никогда так не делайте.

Прежде всего, часто сервисы используют один URI, чтобы определить интерфейс, используя строковые параметры jquery для определения операции, которую нужно выполнить и/или HTTP глагол. Например, чтобы обновить данные покупателя с ID 12345 и получить их в формате JSON может быть использован такой запрос:

GET http://api.example.com/services?op=update_customer&id=12345&format=json

Теперь вы не станете так делать. Несмотря на то, что узел URL-адреса 'services' — существительное, он не является самодокументируемым, поскольку иерархия URI не одна и та же для всех запросов. Кроме того, он использует глагол GET, хотя выполняет обновление. Это контринтуитивно, опасно и вызывает много боли у клиентов.

Вот другой пример, который тоже выполняет обновление данных о покупателе:

GET http://api.example.com/update_customer/12345

И его злобный двойник:

GET http://api.example.com/customers/12345/update

Вы часто можете увидеть последний запрос в сервисах других разработчиков. Заметим, что разработчики стараются создавать RESTful ресурсы и кое-где заметен прогресс. Но лучше, когда вы можете увидеть глагол в URL. Заметьте также, что нам не нужно использовать фразу 'update' в URL, потому что мы можем довериться HTTP глаголу, чтобы сообщить об этой операции. Проясним, что следующий URL избыточен:

PUT http://api.example.com/customers/12345/update

И с PUT, и с 'update' в запросе, мы рискуем запутать потребителей нашего сервиса. Является ли 'update' ресурсом? Мы потратим некоторое время на выяснение этого. Я уверен, вы понимаете.

Давайте поговорим о споре между плюрализаторами и "сингуларизаторами". Вы не слышали об этом споре? Он существует. Соответственно, всё сводится в следующему вопросу:

Должны ли узлы URI в иерархии называться существительными в единственном или множественном числе? Например, как должен выглядеть URI для получения данных о покупателе:

GET http://www.example.com/customer/33245 или GET http://www.example.com/customers/33245

С обеих точек зрения приведены хорошие аргументы, но общепринятой практикой является плюрализация узлов, чтобы обеспечить согласованность для всех HTTP методов. Этот подход обоснован тем, что покупатели считаются коллекцией внутри сервиса и ID (например, 33245) ссылается на одного покупателя из коллекции.

Используя это правило, получим следующие URI с множеством узлов (выделено мной):

GET http://www.example.com/customers/33245/orders/8769/lineitems/1

ноды 'customers', 'orders', и 'lineitems' использованы во множественном числе.

Это подразумевает, что вам нужно только два базовых URL для каждой корневой сущности. Один для создания ресурса внутри коллекции и другой для чтения, обновления и удаления ресурса по его идентификатору. Например, для создания (используя покупателей)

POST http://www.example.com/customers

А для чтения, обновления и удаления следующий:

GET|PUT|DELETE http://www.example.com/customers/{id}

Как было замечено ранее, у ресурса может быть несколько URI, но для минимальных возможностей CRUD'а достаточно всего двух.

Вы можете спросить: есть ли ситуации, когда плюрализация не имеет смысла. Да, фактически есть. Когда в системе не требуется коллекция. Другими словами, приемлем singleton ресурс. Например, если есть единственный всеобъемлющий конфигурационный ресурс, вы можете использовать существительное в единственном числе, чтобы это отразить:

GET|PUT|DELETE http://www.example.com/configuration

Обратите внимание на отсутствие ID и использования глагола POST. Вы скажете, что если бы у каждого покупателя могла быть только одна конфигурация, тогда URL мог бы быть таким:

GET|PUT|DELETE http://www.example.com/customers/12345/configuration

Снова нет никакого ID для конфигурации и нет использования глагола POST. Хотя я уверен, что в обоих случаях можно утверждать, что использование POST является допустимым. Ладно, хорошо.

Примеры URI ресурсов Плохие примеры именования ресурсов Множественность

Что такое Идемпотентность?

Идемпотентность

Идемпотентность - это забавное слово, которое часто выбивает людей из колеи. Идемпотентность кажется иногда запутанной концепцией, по крайней мере, если судить по академическому определению.

С точки зрения RESTful-сервиса, операция (или вызов сервиса) идемпотентна тогда, когда клиенты могут делать один и тот же вызов неоднократно при одном и том же результате, работая как “сеттер” в языке программирования. Другими словами, создание большого количества идентичных запросов имеет такой же эффект, как и один запрос. Заметьте, что в то время, как идемпотентные операции производят один и тот же результат на сервере (побочные эффекты), ответ сам по себе может не быть тем же самым (например, состояние ресурса может измениться между запросами).

Методы PUT и DELETE по определению идемпотентны. Тем не менее есть один нюанс с методом DELETE. Проблема в том, что успешный DELETE-запрос возвращает статус 200 (OK) или 204 (No Content), но для последующих запросов будет всё время возвращать 404 (Not Found), если только сервис не сконфигурирован так, чтобы “помечать” ресурс как удалённый без его фактического удаления. Как бы то ни было, когда сервис на самом деле удаляет ресурс, следующий вызов не найдёт этот ресурс и вернет 404. Состояние на сервере после каждого вызова DELETE то же самое, но ответы разные.

Методы GET, HEAD, OPTIONS и TRACE определены как безопасные, что также делает их идемпотентными. Прочитайте секцию о безопасности ниже.

Безопасность

Некоторые HTTP-методы (например: HEAD, GET, OPTIONS и TRACE) определены как безопасные, это означает, что они предназначены только для получения информации и не должны изменять состояние сервера. Другими словами, они не должны иметь побочных эффектов, за исключением безобидных эффектов, таких как: логирование, кеширование, показ баннерной рекламы или увеличение веб-счетчика. Созданный произвольный GET-запрос, который не учитывает контекст состояния приложения, следует считать безопасным.

Упрощенно, безопасность означает, что вызов метода не имеет побочных эффектов. Следовательно, такие (безопасные) запросы клиенты могут безопасно совершать неоднократно, не опасаясь изменить состояние сервера. Это означает, что сервисы должны придерживаться определения безопасности для GET, HEAD, OPTIONS и TRACE операций. Не выполнения этого свойства может приводить в заблуждение потребителя сервиса, а также вызвать проблемы для веб-кеширования, поисковых систем и других автоматизированных агентов, которые непреднамеренно будут изменять состояние сервера.

По определению, безопасные операции идемпотентны, так как они приводят к одному и тому же результату на сервере.

Безопасные методы реализованы как операции только для чтения. Однако безопасность не означает, что сервер должен возвращать тот же самый результат каждый раз.

Использование HTTP методов для создания RESTful сервисов

HTTP глаголы составляют основную часть “единого интерфейса”, ограничивающего и предоставляющего возможность осуществлять действия над существительным-ресурсом.Основными или наиболее часто используемыми HTTP глаголами (или методами, как их иногда называют) являются POST, GET, PUT, и DELETE. Они соответствуют операциям создания чтения, обновления и удаления (или в совокупности - CRUD). Есть еще и другие глаголы они используются реже. Из реже используемых методов выделяются OPTIONS и HEAD

Ниже приведена сводная таблица рекомендаций по возвращению значений при использовании основных HTTP глаголов в сочетании с ресурсами URI:

HTTP Глагол	Ресурс (например /customers)	Экземпляр (например /customers/{id})
GET	200 (OK), перечень customers. Используется постраничная навигация, сортировка и фильтрация для больших списков.	200 (OK), конкретный customer. 404 (Not Found), в случае отсутствия экземпляра с указанным ID или если он не корректен (а также, если клиенту непозволительно знать о наличии данного экземпляра).
PUT	404 (Not Found), если была попытка обновить/заменить экземпляр во всей коллекции.	200 (OK) или 204 (No Content). 404 (Not Found), в случае отсутствия экземпляра с указанным ID или если он не корректен (а также, если клиенту непозволительно знать о наличии данного экземпляра).
PATCH	405 (Method Not Allowed), если не попытка обновить/заменить всю коллекцию.	200 (OK) или 204 (No Content). 404 (Not Found), в случае отсутствия экземпляра с указанным ID или если он не корректен (а также, если клиенту непозволительно знать о наличии данного экземпляра).
POST	201 (Created), заголовок 'Location' ссылается на /customers/{id}, где ID - идентификатор нового экземпляра.	404 (Not Found).
DELETE	404 (Not Found), если вы хотите удалить всю коллекцию, что крайне не желательно.	200 (OK) или 204 (No Content). 404 (Not Found), в случае отсутствия экземпляра с указанным ID или если он не корректен (а также, если клиенту непозволительно знать о наличии данного экземпляра).

Ниже приводится более подробное обсуждение основных методов HTTP.

HTTP метод GET используется для получения (или чтения) представления ресурса. В случае „удачного” (или не содержащего ошибок) адреса, GET возвращается представление ресурса в формате XML или JSON в сочетании с кодом состояния HTTP 200 (OK). В случае наличия ошибок обычно возвращается код 404 (NOT FOUND) или 400 (BAD REQUEST).

В соответствии спецификации HTTP, GET (так же как и HEAD) запросы используются только для чтения данных, не изменяя их. Таким образом, при соблюдении данного соглашения, они считаются безопасными. То есть они могут использоваться без риска изменения данных, вне зависимости от того, один раз данные были получены, или же 10, или ни разу вовсе. GET (а также HEAD) запросы являются идемпотентными (тождественными), что подразумевает получение идентичных данных при использовании одних и тех же запросов (как при единичном обращении, так и при многократном).

Не стоит использовать GET для небезопасных операций над данными, при данном запросе они не должны быть модифицированы.

Примеры:

GET http://www.example.com/customers/12345
GET http://www.example.com/customers/12345/orders
GET http://www.example.com/buckets/sample

Метод PUT обычно используется для предоставления возможности обновления ресурса. Тело запроса при отправке PUT-запроса к существующему ресурсу URI должно содержать обновленные данные оригинального ресурса (полностью, или только обновляемую часть).

Кроме того, PUT может быть использован для создания ресурса, в случае, когда идентификатор ресурса выбирает клиент, а не сервер. Или, если перефразировать — при отправке PUT запроса по адресу, содержащему не существующий идентификатор ресурса. Опять же, стоит помнить, что тело запроса должно быть модификацией оригинального ресурса. Многие считают это запутанным и непонятным. Соответственно, данную возможность метода PUT стоит использовать с осторожностью. Да и при крайней необходимости.

Для создания новых экземпляров ресурса предпочтительнее использование POST запроса. В данном случае, при создании экземпляра будет предоставлен корректный идентификатор экземпляра ресурса в возвращённых данных об экземпляре.

При успешном обновлении посредством выполнения PUT запроса возвращается код 200 (или 204 если не был передан какой-либо контент в теле ответа). Если PUT используется для создания экземпляра — обычно возвращают HTTP код 201 при успешном создании. Возвращать данные в ответ на запрос необязательно. Также не обязательно возвращать ссылку на экземпляр ресурса посредством заголовка `Location` по причине того, что клиент и так обладает идентификатором экземпляра ресурса.

PUT не безопасная операция, так как вследствие её выполнения происходит модификация (или создание) экземпляров ресурса на стороне сервера, но этот метод идемпотентен. Другими словами, создание или обновление ресурса посредством отправки PUT запроса — ресурс не исчезнет, будет располагаться там же, где и был при первом обращении, а также, многократное выполнение одного и того же PUT запроса не изменит общего состояния системы (за исключением первого раза, но это обычно опускают из рассмотрения)

Если PUT запрос используется для увеличения счётчика просмотра конкретного ресурса — данный запрос уже не считается идемпотентным. Иногда такое происходит и считается достаточным задокументировать тот факт, что вызов не идемпотентен. Однако строго рекомендуется выдерживать идемпотентность PUT запроса.

Примеры:

PUT http://www.example.com/customers/12345
PUT http://www.example.com/customers/12345/orders/98765
PUT http://www.example.com/buckets/secret_stuff

PATCH запрос используется для **модификации** ресурса. PATCH запрос должен содержать только изменяемые данные ресурса, а не все его данные.

Это напоминает работу PUT запроса, но в теле запроса содержится набор инструкций описывающих как должен быть изменён ресурс, расположенный на сервере, для формирования новой версии. Это означает, что тело PATCH запроса должно содержать не просто изменения ресурса, а представлять из себя описание на языке внесения изменений (patch language) таких как JSON Patch или XML Patch.

PATCH запрос ни является безопасным, ни идемпотентным. Однако PATСH запрос может быть сформирован таким образом чтобы быть идемпотентным, что в свою очередь помогает предотвратить негативные последствия от коллизий между двумя PATCH запросами к одному и тому же ресурсу в один и тот же промежуток времени. Коллизии нескольких PATCH запросов могут быть более опасными чем коллизии PUT запросов, потому что некоторым форматам изменений необходимо выполняться от известной базовой-точки или ресурс будет поврежден. Клиенты, использующие такой тип внесения изменений, должны использовать условный запрос на проверку изменения ресурса с момента последнего доступа клиента к нему. Например клиент может использовать ETag в заголовке If-Match в самом PATСH запросе.

Примеры:

PATCH http://www.example.com/customers/12345
PATCH http://www.example.com/customers/12345/orders/98765
PATCH http://www.example.com/buckets/secret_stuff

POST запрос наиболее часто используется для создания новых ресурсов. На практике он используется для создания вложенных ресурсов. Другими словами, при создании нового ресурса, POST запрос отправляется к родительскому ресурсу и, таким образом, сервис берет на себя ответственность на установление связи создаваемого ресурса с родительским ресурсом, назначение новому ресурсу ID и т.п.

При успешном создании ресурса возвращается HTTP код 201, а также в заголовке `Location` передается адрес созданного ресурса.

POST не является безопасным или идемпотентным запросом. Потому рекомендуется его использование для не идемпотентных запросов. В результате выполнения идентичных POST запросов предоставляются сильно похожие, но не идентичные данные.

Примеры:

POST http://www.example.com/customers
POST http://www.example.com/customers/12345/orders

DELETE запрос крайне прост для понимания. Он используется для удаления ресурса, идентифицированного конкретным URI (ID).

При успешном удалении возвращается 200 (OK) код HTTP, совместно с телом ответа, содержащим данные удалённого ресурса (отрицательно сказывается на экономии трафика) или завернутые ответы (Смотрите "Возвращаемые данные"). Также возможно использование HTTP кода 204 (NO CONTENT) без тела ответа.

Согласно спецификации HTTP, DELETE запрос идемпотентен. Если вы выполняете DELETE запрос к ресурсу, он удаляется. Повторный DELETE запрос к ресурсу закончится также: ресурс удалён. Если DELETE запрос используется для декремента счётчика, DELETE запрос не является идемпотентным. Используйте POST для неидемпотентных операций.

Тем не менее, существует предостережение об идемпотентности DELETE. Повторный DELETE запрос к ресурсу часто сопровождается 404 (NOT FOUND) кодом HTTP по причине того, что ресурс уже удалён (например из базы данных) и более не доступен. Это делает DELETE операцию не идемпотентной, но это общепринятый компромисс на тот случай, если ресурс был удалён из базы данных, а не помечен, как удалённый.

Примеры:

DELETE http://www.example.com/customers/12345
DELETE http://www.example.com/customers/12345/orders
DELETE http://www.example.com/bucket/sample

Дополнения и Файлы

Ссылка на оригинальную статью

web_components

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Aug 2023 18:58:48 +0000

Веб-компоненты

Веб-компоненты — это набор различных технологий, позволяющих создавать многократно используемые настраиваемые элементы — с их функциональностью, изолированной от остального кода — и использовать их в своих веб-приложениях.

Концепции и использование Как разработчики, мы все знаем, что повторное использование кода — это хорошая идея. Традиционно это было не так просто для пользовательских структур разметки — подумайте о сложном HTML (и связанном с ним стиле и сценарии), который вам иногда приходилось писать для отображения пользовательских элементов управления пользовательского интерфейса, и о том, как их многократное использование может превратить вашу страницу в беспорядок. если вы не будете осторожны.

Веб-компоненты призваны решить такие проблемы — они состоят из трех основных технологий, которые можно использовать вместе для создания универсальных пользовательских элементов с инкапсулированной функциональностью, которые можно повторно использовать где угодно, не опасаясь коллизий кода.

Пользовательские элементы Набор API-интерфейсов JavaScript, которые позволяют вам определять пользовательские элементы и их поведение, которые затем можно использовать по желанию в вашем пользовательском интерфейсе.

Тень ДОМ Набор API-интерфейсов JavaScript для прикрепления инкапсулированного «теневого» дерева DOM к элементу, который отображается отдельно от основного документа DOM, и управления соответствующей функциональностью. Таким образом, вы можете сохранить свойства элемента в тайне, чтобы их можно было использовать в сценариях и стилях, не опасаясь столкновения с другими частями документа.

HTML-шаблоны Элементы <template>и <slot>позволяют писать шаблоны разметки, которые не отображаются на отображаемой странице. Затем их можно повторно использовать несколько раз в качестве основы структуры пользовательского элемента.

Базовый подход к реализации веб-компонента обычно выглядит примерно так:

Создайте класс, в котором вы указываете функциональность веб-компонента, используя синтаксис класса . Зарегистрируйте новый пользовательский элемент с помощью CustomElementRegistry.define()метода, передав ему имя определяемого элемента, класс или функцию, в которой указаны его функциональные возможности, и, необязательно, элемент, от которого он наследуется. При необходимости прикрепите теневой DOM к пользовательскому элементу с помощью Element.attachShadow()метода. Добавьте дочерние элементы, прослушиватели событий и т. д. в теневой DOM, используя обычные методы DOM. При необходимости определите шаблон HTML с помощью <template>и <slot>. Снова используйте обычные методы DOM, чтобы клонировать шаблон и прикрепить его к теневой модели DOM. Используйте свой пользовательский элемент в любом месте на странице, как и любой обычный элемент HTML. Путеводители Использование пользовательских элементов Руководство, показывающее, как использовать функции пользовательских элементов для создания простых веб-компонентов, а также изучение обратных вызовов жизненного цикла и некоторых других более сложных функций.

Использование теневого DOM Руководство, в котором рассматриваются основы теневого DOM, показывающие, как прикрепить теневой DOM к элементу, добавить его в дерево теневого DOM, стилизовать его и многое другое.

Использование шаблонов и слотов Руководство, показывающее, как определить многократно используемую структуру HTML с помощью элементов <template>и <slot>, а затем использовать эту структуру в веб-компонентах.

Ссылка Пользовательские элементы CustomElementRegistry Содержит функциональные возможности, связанные с пользовательскими элементами, в первую очередь CustomElementRegistry.define()метод, используемый для регистрации новых пользовательских элементов, чтобы их можно было затем использовать в вашем документе.

Window.customElements Возвращает ссылку на CustomElementRegistryобъект.

Обратные вызовы жизненного цикла Специальные функции обратного вызова, определенные внутри определения класса пользовательского элемента, которые влияют на его поведение:

connectedCallback() Вызывается, когда пользовательский элемент впервые подключается к DOM документа.

disconnectedCallback() Вызывается, когда пользовательский элемент отключается от DOM документа.

adoptedCallback() Вызывается, когда пользовательский элемент перемещается в новый документ.

attributeChangedCallback() Вызывается при добавлении, удалении или изменении одного из атрибутов пользовательского элемента.

Расширения для создания пользовательских встроенных элементов Определены следующие расширения:

Глобальный isатрибут HTML Позволяет указать, что стандартный элемент HTML должен вести себя как зарегистрированный настраиваемый встроенный элемент.

Вариант «есть» Document.createElement()метода Позволяет создать экземпляр стандартного HTML-элемента, который ведет себя как заданный зарегистрированный настраиваемый встроенный элемент.

Псевдоклассы CSS Псевдоклассы, относящиеся конкретно к пользовательским элементам:

:defined Соответствует любому определенному элементу, включая встроенные элементы и пользовательские элементы, определенные с помощью CustomElementRegistry.define().

:host Выбирает теневой хост теневого DOM , содержащего CSS, внутри которого он используется.

:host() Выбирает теневой хост теневого DOM , содержащего CSS, внутри которого он используется (так что вы можете выбрать пользовательский элемент внутри его теневого DOM), но только если селектор, указанный в качестве параметра функции, соответствует теневому хосту.

:host-context() Выбирает теневой хост теневого DOM , содержащего CSS, внутри которого он используется (так что вы можете выбрать пользовательский элемент внутри его теневого DOM) — но только если селектор, указанный в качестве параметра функции, соответствует предку(ам) теневого хоста в поместите его внутри иерархии DOM.

Псевдоэлементы CSS Псевдоэлементы, относящиеся конкретно к пользовательским элементам:

::part Представляет любой элемент в теневом дереве , который имеет соответствующий partатрибут.

Тень ДОМ ShadowRoot Представляет корневой узел теневого поддерева DOM.

Elementрасширения Расширения интерфейса Element, связанные с теневым DOM:

Метод Element.attachShadow()прикрепляет теневое дерево DOM к указанному элементу. Свойство Element.shadowRootвозвращает теневой корень, прикрепленный к указанному элементу, или nullесли теневой корень не прикреплен. Соответствующие Nodeдополнения Дополнения к Nodeинтерфейсу, относящиеся к теневому DOM:

Метод Node.getRootNode()возвращает корень объекта контекста, который необязательно включает теневой корень, если он доступен. Свойство Node.isConnectedвозвращает логическое значение, указывающее, подключен ли узел (прямо или косвенно) к объекту контекста, например, к объекту Documentв случае обычного DOM или ShadowRootв случае теневого DOM. Eventрасширения Расширения интерфейса Event, связанные с теневым DOM:

Event.composed Возвращает значение true, если событие будет распространяться через границу теневого DOM в стандартный DOM, в противном случае false.

Event.composedPath Возвращает путь события (объекты, для которых будут вызываться прослушиватели). Это не включает узлы в теневых деревьях, если теневой корень был создан с ShadowRoot.modeзакрытым.

HTML-шаблоны <template> Содержит фрагмент HTML, который не отображается при первоначальной загрузке содержащего документа, но может отображаться во время выполнения с помощью JavaScript, который в основном используется в качестве основы для структур пользовательских элементов. Связанный интерфейс DOM — HTMLTemplateElement.

<slot> Заполнитель внутри веб-компонента, который можно заполнить собственной разметкой, что позволяет создавать отдельные деревья DOM и представлять их вместе. Связанный интерфейс DOM — HTMLSlotElement.

Глобальный slotатрибут HTML Назначает элементу слот в теневом дереве теневого DOM.

Element.assignedSlot Атрибут только для чтения, который возвращает ссылку на элемент, <slot>в который вставлен этот элемент.

Text.assignedSlot Доступный только для чтения атрибут, возвращающий ссылку на элемент, <slot>в который вставлен этот текстовый узел.

Elementрасширения Расширения интерфейса Element, связанные со слотами:

Element.slot Возвращает имя теневого слота DOM, прикрепленного к элементу.

Псевдоэлементы CSS Псевдоэлементы, относящиеся конкретно к слотам:

::slotted Соответствует любому содержимому, которое вставляется в слот.

событие slotchange_ Запускается для HTMLSlotElementэкземпляра ( <slot>элемента), когда узлы, содержащиеся в этом слоте, изменяются.

Примеры Мы создаем ряд примеров в нашем репозитории GitHub с примерами веб-компонентов . Со временем будет добавлено больше.

webgl_api

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Aug 2023 18:01:10 +0000

WebGL: 2D- и 3D-графика для Интернета.

WebGL (библиотека веб-графики) — это API JavaScript для рендеринга высокопроизводительной интерактивной 3D- и 2D-графики в любом совместимом веб-браузере без использования подключаемых модулей. WebGL делает это путем введения API, который полностью соответствует OpenGL ES 2.0 и который можно использовать в <canvas>элементах HTML. Это соответствие позволяет API использовать преимущества аппаратного ускорения графики, обеспечиваемого устройством пользователя.

Поддержка WebGL присутствует во всех современных браузерах (см. таблицы совместимости ниже); однако устройство пользователя также должно иметь оборудование, поддерживающее эти функции.

API WebGL 2 обеспечивает поддержку большей части набора функций OpenGL ES 3.0; это предоставляется через WebGL2RenderingContextинтерфейс.

Этот <canvas>элемент также используется API Canvas для создания 2D-графики на веб-страницах.

Ссылка Стандартные интерфейсы WebGLRenderingContext WebGL2RenderingContext WebGLActiveInfo WebGLBuffer WebGLContextEvent WebGLFramebuffer WebGLProgram WebGLQuery WebGLRenderbuffer WebGLSampler WebGLShader WebGLShaderPrecisionFormat WebGLSync WebGLTexture WebGLTransformFeedback WebGLUniformLocation WebGLVertexArrayObject Расширения ANGLE_instanced_arrays EXT_blend_minmax EXT_color_buffer_float EXT_color_buffer_half_float EXT_disjoint_timer_query EXT_float_blend Экспериментальный EXT_frag_depth EXT_shader_texture_lod EXT_sRGB EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_norm16 KHR_parallel_shader_compile OES_draw_buffers_indexed OES_element_index_uint OES_fbo_render_mipmap OES_standard_derivatives OES_texture_float OES_texture_float_linear OES_texture_half_float OES_texture_half_float_linear OES_vertex_array_object OVR_multiview2 WEBGL_color_buffer_float WEBGL_compressed_texture_astc WEBGL_compressed_texture_etc WEBGL_compressed_texture_etc1 WEBGL_compressed_texture_pvrtc WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_depth_texture WEBGL_draw_buffers WEBGL_lose_context WEBGL_multi_draw События webglcontextlost webglcontextrestored webglcontextcreationerror Константы и типы Константы WebGL Типы WebGL WebGL 2 WebGL 2 — это крупное обновление WebGL, предоставляемое через WebGL2RenderingContextинтерфейс. Он основан на OpenGL ES 3.0 и включает в себя новые функции:

3D текстуры , Объекты сэмплера , Объекты Uniform Buffer , Синхронизировать объекты , Объекты запроса , Преобразовать объекты обратной связи , Продвинутые расширения, которые теперь являются ядром WebGL 2: объекты Vertex Array , создание экземпляров , несколько целей рендеринга , глубина фрагмента . См. также сообщение в блоге «WebGL 2 в Firefox» и на веб-сайте webglsamples.org/WebGL2Samples , где можно найти несколько демонстраций.

Руководства и учебные пособия Ниже вы найдете ряд руководств, которые помогут вам изучить концепции WebGL, а также учебные пособия, содержащие пошаговые уроки и примеры.

Путеводители Данные в WebGL Руководство по переменным, буферам и другим типам данных, используемым при написании кода WebGL.

Лучшие практики WebGL Советы и предложения, которые помогут вам улучшить качество, производительность и надежность вашего контента WebGL.

Использование расширений Руководство по использованию расширений WebGL.

Учебники Учебное пособие по WebGL Руководство для начинающих по основным понятиям WebGL. Хорошее место для начала, если у вас нет опыта работы с WebGL.

Примеры Базовый пример 2D-анимации WebGL Этот пример демонстрирует простую анимацию одноцветной фигуры. Рассмотренные темы включают адаптацию к различиям в пропорциях, функцию создания шейдерных программ из наборов нескольких шейдеров и основы рисования в WebGL.

WebGL на примере Серия живых примеров с краткими пояснениями, демонстрирующих концепции и возможности WebGL. Примеры отсортированы по темам и уровням сложности и охватывают контекст рендеринга WebGL, программирование шейдеров, текстуры, геометрию, взаимодействие с пользователем и многое другое.

Расширенные учебные пособия Проекция вида модели WebGL Подробное объяснение трех основных матриц, которые обычно используются для представления вида трехмерного объекта: матрицы модели, вида и проекции.

Матричная математика для Интернета Полезное руководство о том, как работают матрицы 3D-преобразований, которое можно использовать в Интернете — как для вычислений WebGL, так и в преобразованиях CSS.

Ресурсы Сайт Khronos WebGL Главный веб-сайт WebGL группы Khronos. Основы WebGL Базовое руководство по основам WebGL. Raw WebGL: введение в WebGL Выступление Ника Десолнье, знакомящее с основами WebGL. Игровая площадка WebGL Онлайн-инструмент для создания и совместного использования проектов WebGL. Подходит для быстрого прототипирования и экспериментов. WebGL Academy Редактор HTML/JavaScript с обучающими материалами для изучения основ программирования WebGL. WebGL Stats Сайт со статистикой возможностей WebGL в браузерах на разных платформах. Библиотеки Three.js — это полнофункциональная 3D-библиотека WebGL с открытым исходным кодом. Babylon.js — это мощный, простой и открытый движок игр и 3D-рендеринга, упакованный в дружественную среду JavaScript. Pixi.js — это быстрый 2D-рендерер WebGL с открытым исходным кодом. Phaser — это быстрая, бесплатная и увлекательная платформа с открытым исходным кодом для браузерных игр на основе Canvas и WebGL. PlayCanvas — игровой движок с открытым исходным кодом. glMatrix — это библиотека матриц и векторов JavaScript для высокопроизводительных приложений WebGL. twgl — это библиотека, позволяющая сделать webgl менее многословным. RedGL — это 3D-библиотека WebGL с открытым исходным кодом. vtk.js — это библиотека JavaScript для научной визуализации в вашем браузере. webgl-lint поможет найти ошибки в вашем коде WebGL и предоставит полезную информацию.

webvtt_api

anonymous@undisclosed.example.com (Anonymous) — Tue, 22 Aug 2023 17:05:56 +0000

WebVTT (Формат текстовых дорожек веб-видео)

Формат текстовых дорожек веб-видео ( WebVTT ) — это формат для отображения синхронизированных текстовых дорожек (например, субтитров или заголовков) с использованием этого <track>элемента. Основная цель файлов WebVTT — добавление текстовых наложений в файл <video>. WebVTT — это текстовый формат, который должен быть закодирован с использованием UTF-8 . Там, где вы можете использовать пробелы, вы также можете использовать табуляции. Существует также небольшой API для представления и управления этими треками и данными, необходимыми для воспроизведения текста в нужное время.

Файлы WebVTT MIME-тип WebVTT — text/vtt.

Файл WebVTT ( .vtt) содержит сигналы, которые могут состоять из одной или нескольких строк, как показано ниже:

WEBVTT

00:01.000 –> 00:04.000 - Never drink liquid nitrogen.

00:05.000 –> 00:09.000 - It will perforate your stomach. - You could die. Тело WebVTT Структура WebVTT состоит из следующих компонентов (некоторые из них необязательные) в следующем порядке:

Дополнительный знак порядка байтов (BOM). Строка « WEBVTT». Необязательный текстовый заголовок справа от WEBVTT. После . должен быть хотя бы один пробел WEBVTT. Вы можете использовать это, чтобы добавить описание к файлу. В текстовом заголовке вы можете использовать что угодно, кроме символов новой строки или строки « –>». Пустая строка, эквивалентная двум последовательным символам новой строки. Ноль или более реплик или комментариев. Ноль или более пустых строк. Примеры Простейший файл WebVTT WEBVTT Очень простой файл WebVTT с текстовым заголовком. WEBVTT - This file has no cues. Общий пример WebVTT с заголовком и сигналами WEBVTT - This file has cues.

14 00:01:14.815 –> 00:01:18.114 - What? - Where are we now?

15 00:01:18.171 –> 00:01:20.991 - This is big bat country.

16 00:01:21.058 –> 00:01:23.868 - [ Bats Screeching ] - They won't get in your hair. They're after the bugs. Внутренняя структура файла WebVTT Давайте еще раз рассмотрим один из наших предыдущих примеров и рассмотрим структуру сигнала более подробно.

WEBVTT

00:01.000 –> 00:04.000 - Never drink liquid nitrogen.

00:05.000 –> 00:09.000 - It will perforate your stomach. - You could die. В случае каждого сигнала:

Первая строка начинается со времени, которое является временем начала отображения текста, который появляется под ней. В той же строке у нас есть строка « –>». Мы заканчиваем первую строку вторым временем, которое является временем окончания отображения связанного текста. Затем мы можем иметь одну или несколько строк, начинающихся с дефиса (-), каждая из которых будет содержать часть отображаемой текстовой дорожки. Мы также можем размещать комментарии в нашем .vttфайле, чтобы помочь нам запомнить важную информацию о частях нашего файла. Они должны быть на отдельных строках, начиная со строки NOTE. Подробнее об этом вы найдете в разделе ниже.

Важно не использовать «лишние» пустые строки внутри вызова, например, между строкой таймингов и полезной нагрузкой сигнала. WebVTT основан на линиях; пустая строка закроет вызов.

Комментарии WebVTT Комментарии — это необязательный компонент, который можно использовать для добавления информации в файл WebVTT. Комментарии предназначены для тех, кто читает файл, и не видны пользователям. Комментарии могут содержать символы новой строки, но не могут содержать пустую строку, которая эквивалентна двум последовательным символам новой строки. Пустая строка означает конец комментария.

Комментарий не может содержать строку –>, символ амперсанда ( &) или знак «меньше» ( <). Если вы хотите использовать такие символы, вам необходимо экранировать их, используя, например, &амперсанд и <меньше. Также рекомендуется использовать escape-последовательность «больше чем» ( >) вместо символа «больше чем» ( >), чтобы избежать путаницы с тегами.

Комментарий состоит из трех частей:

Строка NOTE. Пробел или новая строка. Ноль или более символов, кроме указанных выше. Примеры Общий пример WebVTT NOTE This is a comment Многострочный комментарий NOTE One comment that is spanning more than one line.

NOTE You can also make a comment across more than one line this way. Обычное использование комментариев WEBVTT - Translation of that film I like

NOTE This translation was done by Kyle so that some friends can watch it with their parents.

1 00:02:15.000 –> 00:02:20.000 - Ta en kopp varmt te. - Det är inte varmt.

2 00:02:20.000 –> 00:02:25.000 - Har en kopp te. - Det smakar som te.

NOTE This last line may not translate well.

3 00:02:25.000 –> 00:02:30.000 - Ta en kopp Стилизация сигналов WebVTT Вы можете стилизовать сигналы WebVTT, ища элементы, соответствующие псевдоэлементу ::cue.

CSS сайта CSS Скопировать в буфер обмена

video::cue {

background-image: linear-gradient(to bottom, dimgray, lightgray);
color: papayawhip;

}

video::cue(b) {

color: peachpuff;

} Здесь все видеоэлементы оформлены с использованием серого линейного градиента в качестве фона с цветом переднего плана «papayawhip». Кроме того, текст, выделенный жирным шрифтом с использованием этого элемента, окрашивается «peachpuff».

Приведенный ниже фрагмент HTML фактически управляет отображением самого мультимедиа.

HTML Скопировать в буфер обмена

<track default src="track.vtt" />

</video> Внутри самого файла WebVTT Вы также можете определить стиль непосредственно в файле WebVTT. В этом случае вы вставляете свои правила CSS в файл, причем каждому правилу предшествует строка «STYLE»в строке текста, как показано ниже:

WEBVTT

STYLE ::cue {

background-image: linear-gradient(to bottom, dimgray, lightgray);
color: papayawhip;

} /* Style blocks cannot use blank lines nor «dash dash greater than» */

NOTE comment blocks can be used between style blocks.

STYLE ::cue(b) {

color: peachpuff;

}

00:00:00.000 –> 00:00:10.000 - Hello world.

NOTE style blocks cannot appear after the first cue. Мы также можем использовать идентификаторы внутри файла WebVTT, которые можно использовать для определения нового стиля для некоторых конкретных сигналов в файле. Пример, в котором мы хотели, чтобы текст транскрипции был выделен красным цветом, а другая часть оставалась нормальной, мы можем определить его следующим образом с помощью CSS. Следует отметить, что CSS использует escape-последовательности так же, как они используются на страницах HTML:

WEBVTT

1 00:00.000 –> 00:02.000 That's an, an, that's an L!

crédit de transcription 00:04.000 –> 00:05.000 Transcrit par Célestes™ CSS Скопировать в буфер обмена

::cue(#\31) {

color: lime;

} ::cue(#crédit\ de\ transcription) {

color: red;

} Также поддерживается позиционирование текстовых дорожек путем включения информации о позиционировании после тайминга в метку, как показано ниже ( дополнительную информацию см. в разделе Настройки метки ):

WEBVTT

00:00:00.000 –> 00:00:04.000 position:10%,line-left align:left size:35% Where did he go?

00:00:03.000 –> 00:00:06.500 position:90% align:right size:35% I think he went down this lane.

00:00:04.000 –> 00:00:06.500 position:45%,line-right align:center size:35% What are you waiting for? Сигналы WebVTT Сигнал — это отдельный блок субтитров, который имеет одно время начала, время окончания и текстовую нагрузку. Кий состоит из пяти компонентов:

Необязательный идентификатор сигнала, за которым следует новая строка. Тайминги реплик. Дополнительные настройки метки, по крайней мере, с одним пробелом перед первой и между каждой настройкой. Одна новая строка. Текст полезной нагрузки сигнала. Вот пример реплики:

1 - Title Crawl 00:00:05.000 –> 00:00:10.000 line:0 position:20% size:60% align:start Some time ago in a place rather distant…. Идентификатор сигнала Идентификатор — это имя, которое идентифицирует сигнал. Его можно использовать для ссылки на реплику из сценария. Он не должен содержать новой строки и не может содержать строку « –>». Он должен заканчиваться одной новой строкой. Они не обязательно должны быть уникальными, хотя их принято нумеровать (например, 1, 2, 3).

Вот несколько примеров:

Базовый идентификатор сигнала 1 - Title Crawl Общее использование идентификаторов WEBVTT

1 00:00:22.230 –> 00:00:24.606 This is the first subtitle.

2 00:00:30.739 –> 00:00:34.074 This is the second.

3 00:00:34.159 –> 00:00:35.743 Third Тайминги меток Время сигнала указывает, когда сигнал отображается. У него есть время начала и окончания, которые представлены метками времени. Время окончания должно быть больше времени начала, а время начала должно быть больше или равно всем предыдущим временам начала. Сигналы могут иметь перекрывающиеся тайминги.

Если файл WebVTT используется для глав ( is ), тогда в файле не может быть перекрывающихся таймингов.<track> kindchapters

Каждый тайминг сигнала содержит пять компонентов:

Временная метка времени начала. Хотя бы одно место. Строка « –>». Хотя бы одно место. Временная метка времени окончания, которая должна быть больше времени начала. Временные метки должны быть в одном из двух форматов:

mm:ss.ttt hh:mm:ss.ttt Где компоненты определены следующим образом:

hh Представляет часы и должно состоять как минимум из двух цифр. Оно может быть больше двух цифр (например, 9999:00:00.000).

mm Представляет минуты и должно находиться в диапазоне от 00 до 59 включительно.

ss Представляет секунды и должно находиться в диапазоне от 00 до 59 включительно.

ttt Представляет миллисекунды и должно находиться в диапазоне от 000 до 999 включительно.

Вот несколько примеров тайминга сигналов:

Основные примеры синхронизации сигналов 00:00:22.230 –> 00:00:24.606 00:00:30.739 –> 00:00:34.074 00:00:34.159 –> 00:00:35.743 00:00:35.827 –> 00:00:40.122 Примеры перекрывающихся сигналов синхронизации 00:00:00.000 –> 00:00:10.000 00:00:05.000 –> 00:01:00.000 00:00:30.000 –> 00:00:50.000 Примеры неперекрывающихся сигналов синхронизации 00:00:00.000 –> 00:00:10.000 00:00:10.000 –> 00:01:00.581 00:01:00.581 –> 00:02:00.100 00:02:01.000 –> 00:02:01.000 Настройки сигнала Настройки метки — это дополнительные компоненты, используемые для определения места, где текст полезной нагрузки метки будет отображаться поверх видео. Это включает в себя то, отображается ли текст горизонтально или вертикально. Их может быть ноль или более, и их можно использовать в любом порядке, при условии, что каждый параметр используется не более одного раза.

Настройки сигнала добавляются справа от времени сигнала. Между моментом сигнала и первой настройкой, а также между каждой настройкой должен быть один или несколько пробелов. Имя и значение параметра разделяются двоеточием. Настройки чувствительны к регистру, поэтому используйте строчные буквы, как показано. Существует пять настроек сигнала:

vertical Указывает, что текст будет отображаться вертикально, а не горизонтально, как, например, в некоторых азиатских языках. Возможны два значения:

rl Направление письма справа налево.

lr Направление письма слева направо

line Если параметр «вертикаль» не установлен, указывает, где текст будет располагаться вертикально. Если задано значение «Вертикально», линия указывает, где текст будет располагаться по горизонтали. Его значение может составлять:

номер строки Число — это высота первой строки реплики, как она отображается на видео. Положительные числа указывают сверху вниз, а отрицательные числа указывают снизу вверх.

процент Оно должно быть целым числом (т. е. без десятичных знаков) от 0 до 100 включительно, после которого должен стоять знак процента (%).

Линия verticalопущен vertical:rl vertical:lr line:0 вершина верно левый line:-1 нижний левый верно line:0% вершина верно левый line:100% нижний левый верно position Указывает, где текст будет отображаться по горизонтали. Если задано значение «вертикально», позиция определяет, где текст будет отображаться вертикально. Значение представляет собой процент, то есть целое число (без десятичных знаков) от 0 до 100 включительно, за которым следует знак процента (%).

Позиция verticalопущен vertical:rl vertical:lr position:0% левый вершина вершина position:100% верно нижний нижний size Определяет ширину текстовой области. Если установлено значение «Вертикально», размер определяет высоту текстовой области. Значение представляет собой процент, то есть целое число (без десятичных знаков) от 0 до 100 включительно, за которым следует знак процента (%).

Размер verticalопущен vertical:rl vertical:lr size:100% полная ширина полная высота полная высота size:50% половина ширины половина высоты половина высоты align Задает выравнивание текста. Текст выравнивается в пределах пространства, заданного настройкой метки размера, если она установлена.

Выровнять verticalопущен vertical:rl vertical:lr align:start левый вершина вершина align:center центрировано по горизонтали центрировано по вертикали центрировано по вертикали align:end верно нижний нижний Разберем пример настройки сигнала.

Первая строка демонстрирует отсутствие настроек. Вторая строка может использоваться для наложения текста на знак или этикетку. Третья строка может использоваться для заголовка. Последняя строка может использоваться для азиатского языка.

00:00:05.000 –> 00:00:10.000 00:00:05.000 –> 00:00:10.000 line:63% position:72% align:start 00:00:05.000 –> 00:00:10.000 line:0 position:20% size:60% align:start 00:00:05.000 –> 00:00:10.000 vertical:rt line:-1 align:end Полезная нагрузка сигнала Полезная нагрузка — это место, где находится основная информация или контент. При обычном использовании полезная нагрузка содержит отображаемые субтитры. Текст полезных данных может содержать символы новой строки, но не может содержать пустую строку, которая эквивалентна двум последовательным символам новой строки. Пустая строка означает конец реплики.

Полезные данные ключевого текста не могут содержать строку –>, символ амперсанда ( &) или знак «меньше» ( <). Вместо этого используйте escape-последовательность &для амперсанда и <меньше чем. Также рекомендуется использовать escape-последовательность «больше чем» >вместо символа «больше» ( >), чтобы избежать путаницы с тегами. Если вы используете файл WebVTT для метаданных, эти ограничения не применяются.

Помимо трех упомянутых выше escape-последовательностей, есть еще четыре. Они перечислены в таблице ниже.

Имя Характер Последовательность выхода Амперсанд & & Меньше, чем < < Больше чем > > Отметка слева направо никто &lrm; Метка справа налево никто &rlm; Неразрывное пространство   Текстовые теги полезной нагрузки Можно использовать ряд тегов, например . Однако если файл WebVTT используется в элементе, где указан <track>атрибут, вы не можете использовать теги.kindchapters

Метка времени Временная метка должна быть больше, чем временная метка начала вызова, больше, чем любая предыдущая временная метка в полезных данных вызова, и меньше, чем временная метка окончания вызова. Активный текст — это текст между меткой времени и следующей меткой времени или до конца полезных данных, если в полезных данных нет другой метки времени. Любой текст перед активным текстом в полезных данных является предыдущим текстом . Любой текст за пределами активного текста является будущим текстом . Это позволяет использовать субтитры в стиле караоке.

1 00:16.500 –> 00:18.500 When the moon <00:17.500>hits your eye

1 00:00:18.500 –> 00:00:20.500 Like a <00:19.000>big-a <00:19.500>pizza <00:20.000>pie

1 00:00:20.500 –> 00:00:21.500 That's <00:00:21.000>amore Следующие теги являются тегами HTML, разрешенными в вызове, и требуют открытия и закрытия тегов (например, text).

Тег класса ( <c></c>) Оформите содержащийся текст с помощью класса CSS.