Re: [whatwg] HTML tags for POEM and MUSIC LYRICS

On Sun, Nov 26, 2017 at 8:59 AM, GevCbmlGM wrote: > Hi, > > Is there any recommend standard HTML tags for POEM and MUSIC LYRICS? > > I searched and did not see anyone talk about it. > But I see different creative way people come up for POEM / STANZA / LINE > > 1. > > > 2. > > > 3. > > > 4

Re: [whatwg] [csswg][css-display] Updated WD of CSS Display L3

On Thu, Feb 2, 2017 at 12:46 PM, Boris Zbarsky wrote: > On 2/2/17 2:28 PM, fantasai wrote: >> >> On 02/02/2017 01:18 PM, Boris Zbarsky wrote: >>> >>> OK, so if I have a flex container with two kids, a run-in and a block, >>> do I get one flex item or two flex items and why? And >>> did that requi

Re: [whatwg] [css-display] CSS Display Review

On Tue, Sep 20, 2016 at 1:15 AM, Simon Pieters wrote: > On Tue, 20 Sep 2016 02:54:56 +0200, Boris Zbarsky wrote: >> On 9/20/16 1:46 AM, Mats Palmgren wrote: >>> >>> Assuming that the above are the final DOM trees, then they should >>> create exactly the same CSS boxes as if the element is replac

Re: [whatwg] proposal for new inputmode: digits

On Mon, Jul 25, 2016 at 3:35 PM, Nils Dagsson Moskopp wrote: > Eitan Adler writes: > >> On 25 July 2016 at 14:59, Nils Dagsson Moskopp < >> n...@dieweltistgarnichtso.net> wrote: >> >>> Eitan Adler writes: >>> > See also the remainder of my email. >>> >>> I do not understand. What do you mean? >>

Re: [whatwg] : Issue reported by the web developers

So, here's one example of a page putting content inside of : https://developer.apple.com/library/prerelease/ios/documentation/HealthKit/Reference/HealthKit_Constants/index.html#//apple_ref/c/econst/HKBodyTemperatureSensorLocationRectum If you use Chrome with the Experimental Web Platform Features

Re: [whatwg] How to add html5 browser support

On Thu, Sep 3, 2015 at 10:45 AM, Brian Jones wrote: > I'm taking online class to program a browser from scratch. How do I > add Html5 support? Thank you. -Brian Jones You read the spec and then implement all of it. Mind you, it might take a few days. ~T

Re: [whatwg] Inline SVG: Embedded vs. Metadata Content Distinction (Was: Fwd: Allow Select SVG Elements In )

On Sat, Aug 29, 2015 at 12:51 AM, Hugh Guiney wrote: > Bueller...? Bueller...? > > This request is almost 5 years old now, but it is even more relevant today, > now that web developers are increasingly embracing SVG for purposes of > responsive design and accommodating HiDPI displays. > > Putting

Re: [whatwg] DOM Events Proposal: EventListenerOptions 'mayCancel' for improved scroll performance

On Wed, Jul 8, 2015 at 12:12 PM, Rick Byers wrote: > [Cross-posted to www-...@w3.org - please let me know if there's a better > way to account for the DOM spec duality] > > In Chromium we've long worked hard at maximizing scroll performance, with > scroll-blocking DOM events (wheel and touchstart

Re: [whatwg] A mask="" advisory flag for

On Jun 26, 2015 14:30, "Edward O'Connor" wrote: > > Hi Tab, > > You wrote: > > >>> Sounds acceptable to me. What's the grammar of color=''? Just hex, > >>> or full CSS ? (Either is fine with me.) > >> > >> We support full CSS colors. Though, we ignore the alpha component. > > > > Cool. When are we

Re: [whatwg] A mask="" advisory flag for

On Fri, Jun 26, 2015 at 10:17 AM, Timothy Hatcher wrote: > On Jun 24, 2015, at 2:39 PM, Tab Atkins Jr. wrote: >> Sounds acceptable to me. What's the grammar of color=''? Just hex, >> or full CSS ? (Either is fine with me.) > > We support full CSS colors. T

Re: [whatwg] A mask="" advisory flag for

On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak wrote: > To close the loop on this, we will change to href="whatever.svg" color="#aabbcc">. We like the idea of determining the > color from the SVG, but we won't be able to implement in time for this cycle, > and having an explicit color overr

Re: [whatwg] IPv4 parsing

On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren wrote: > On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. wrote: >> You swap between 0.0.0.66 and 66.0.0.0 in your OP. > > Actually, the input URL in that case is different. 0x42.0. != 0x42. Well *that's* confusing. ^_^ Def

Re: [whatwg] IPv4 parsing

On Wed, Jun 24, 2015 at 7:21 AM, Anne van Kesteren wrote: > On Wed, Jun 24, 2015 at 3:46 AM, timeless wrote: >> You have http://0.0.0.66/ that's not a match for your example... > > I'm not sure what you mean here. You swap between 0.0.0.66 and 66.0.0.0 in your OP. ~TJ

Re: [whatwg] support for named colors in (was Re: Icon mask and theme color)

On Thu, Jun 18, 2015 at 10:35 AM, Edward O'Connor wrote: >>> On the other hand, seems >>> like it should Just Work™. >> >> I guess we could add support for named colors to >> too. > > Offhand I think that's a good idea. Probably won't round-trip through > typical color picker implementations, bu

Re: [whatwg] Shared workers with worker parents

On Fri, Jun 19, 2015 at 3:55 PM, James Burke wrote: > For some of the apps that run on Firefox OS, we want to use a Service > Worker to handle a background sync message, but allow that Service > Worker to contact a Shared Worker to do the work. This allows the > app's open browser windows, which a

Re: [whatwg] Icon mask and theme color

On Wed, Jun 17, 2015 at 5:16 PM, Karl Dubost wrote: > Tab, > > (summary: let's put the information inside the SVG file, more below) > > Le 18 juin 2015 à 08:41, Tab Atkins Jr. a écrit : >> better than color averaging. Averaging seems like it would >> rarely p

Re: [whatwg] Icon mask and theme color

On Tue, Jun 16, 2015 at 11:51 PM, Smylers wrote: > Maciej Stachowiak writes: >> We do have a requirement to have the mask icons render with a single >> color. I don’t think the approach suggested here is very good. Color >> averaging would not be very predictable in its results and could be >> uns

Re: [whatwg] A mask="" advisory flag for

On Tue, Jun 16, 2015 at 9:49 PM, Anne van Kesteren wrote: > On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr. wrote: >> Before we start bikeshedding, can you commit to actually changing your >> implementation? Safari has already shipped with the exact proposal >> given in t

Re: [whatwg] A mask="" advisory flag for

On Tue, Jun 16, 2015 at 2:36 PM, Elliott Sprehn wrote: > On Tue, Jun 16, 2015 at 2:33 PM, Tab Atkins Jr. > wrote: >> On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn >> wrote: >> > On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. >> > wrote: >> >>

Re: [whatwg] Icon mask and theme color

On Mon, Jun 15, 2015 at 12:00 PM, Maciej Stachowiak wrote: > For similar reasons, it seemed better to reuse the existing theme-color meta > (which gives license to darken or lighten the color as needed). Agreed; along with Ted's observation that theme-color hits at least the 80/20 use-case, I do

Re: [whatwg] A mask="" advisory flag for

On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn wrote: > On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. > wrote: >> On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn >> wrote: >> > sizes is a generic feature that's available for all image resources. >>

Re: [whatwg] A mask="" advisory flag for

On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn wrote: > sizes is a generic feature that's available for all image resources. No it's not; and are completely unrelated. ~TJ

Re: [whatwg] A mask="" advisory flag for

On Tue, Jun 16, 2015 at 1:51 PM, Edward O'Connor wrote: > Hi Elliott, > > You wrote: >> I'm fine with either interpretation, mask-icon or "icon mask" like >> "alternate stylesheet". I don't think adding a mask attribute to the >> HTMLLinkElement for this makes sense. > > Could you elaborate? It's

Re: [whatwg] A mask="" advisory flag for

On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor wrote: > Authors would provide a mask icon like so: > > [...] > P.S. OK, bikeshedding. What should we call the attribute? The ideal name > says something about the icon and not about how a UA might use it. There > are a few properties of the i

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Fri, May 8, 2015 at 10:13 AM, Anne van Kesteren wrote: > On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. wrote: >> I don't think ascii case-insensitivity is a mistake here. > > (ASCII) case-insensitivity is a mistake. JavaScript doesn't have it > and wherever we do

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Fri, May 8, 2015 at 9:09 AM, Boris Zbarsky wrote: > On 5/8/15 11:56 AM, Roger Hågensen wrote: >> One way to cheapen the computational cost is to have partial case >> insensitive matching. > > If you're walking the string at all, you have already lost in terms of > performance for this stuff. L

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 10:42 PM, Anne van Kesteren wrote: > On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. wrote: >> Well, beyond the existing conflicts of

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 2:11 PM, Elliott Sprehn wrote: > On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky wrote: >> On 5/7/15 5:07 PM, Tab Atkins Jr. wrote: >>> I believe the SVGWG is fine with a parsing-based approach, exactly >>> like what HTML does. An SVG element cr

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 8:26 AM, Boris Zbarsky wrote: > Note that at least for this matters, in that you could suddenly > have selectors that are not meant to match it start matching it. That's not part of SVG1.1 or SVG2; it's not supported on most (all?) major browsers anyway, so that's not a bi

Re: [whatwg] Case-sensitivity of CSS type selectors in HTML

On Thu, May 7, 2015 at 4:16 AM, Rune Lillesveen wrote: > Currently, the HTML spec says that type selectors matches case > sensitively for non-html elements like svg elements in html documents > [1]. So according to the spec, and the implementation in Gecko, the > rules below matches according to t

Re: [whatwg] EventSource and data URLs

On Mon, Apr 27, 2015 at 3:58 PM, Jonas Sicking wrote: > On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. wrote: >> On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren wrote: >>> Currently Chrome supports data URLs inside EventSource whereas in >>> Firefox EventSource

Re: [whatwg] EventSource and data URLs

On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren wrote: > Currently Chrome supports data URLs inside EventSource whereas in > Firefox EventSource is restricted to http/https URLs: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1156137 > > What's the convergence we want here? It's rather fru

Re: [whatwg] Canvas image to blob/dataurl within Worker

On Tue, Apr 14, 2015 at 10:53 PM, Robert O'Callahan wrote: > I guess there are really two different sets of use-cases: > 1) Use-cases where the ImageBitmap is sized to fill a particular area of > the screen. > 2) Use-cases where the ImageBitmap is sized subject to some other > constraints, e.g. yo

Re: [whatwg] Responsive image maps

On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine wrote: >> Instead, we start by figuring out what problems need solving. > Which is what has been done for this subject, I guess. > PROBLEM: image maps, intended as "shaped link areas related to specific > regions of an image" are a fairly requested

Re: [whatwg] Responsive image maps

On Fri, Mar 20, 2015 at 1:30 PM, Andrea Rendine wrote: > SVG can be resized. Everything inside it cannot, as far as it is not defined > by relative units. If you use percentage coordinates, or use px coordinates plus a viewBox attribute on the , the stuff inside resizes along with the container

Re: [whatwg] Responsive image maps

On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine wrote: > About SVG, I made a couple of tests and they are far from being > comprehensive, but this is the fact. SVG image "maps" need to define 2 > elements for each "area", i.e. the element itself and its associated > hyperlink. That's really not m

Re: [whatwg] Responsive image maps

On Fri, Mar 20, 2015 at 12:22 PM, Martin Janecke wrote: > However, since image maps have been an integral part of HTML since version > 3.2 and not been deprecated in favor of a better alternative yet, it might > still be a straightforward solution to enhance them. Responsive image maps > would be

Re: [whatwg] Effect of image-orientation on naturalWidth/Height

On Fri, Mar 13, 2015 at 12:21 PM, Seth Fowler wrote: > >> On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. wrote: >> >> If it happens at the markup level, it should *definitely* affect the >> naturalWidth/Height properties. I don't think that's in question

Re: [whatwg] Effect of image-orientation on naturalWidth/Height

On Tue, Mar 10, 2015 at 1:29 AM, Anne van Kesteren wrote: > On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler wrote: >> I wanted to get the opinion of this list on how image-orientation and the >> element’s naturalWidth and naturalHeight properties should interact. > > I thought there was some agre

Re: [whatwg] Persistent and temporary storage

On Fri, Mar 13, 2015 at 6:58 AM, Janusz Majnert wrote: > On 13.03.2015 13:50, Anne van Kesteren wrote: >> A big gap with native is dependable storage for applications. I >> started sketching the problem space on this wiki page: >> >>https://wiki.whatwg.org/wiki/Storage >> >> Feedback I got is

Re: [whatwg] Effect of image-orientation on naturalWidth/Height

On Mon, Mar 9, 2015 at 4:01 PM, Seth Fowler wrote: > Hi all! > > I wanted to get the opinion of this list on how image-orientation and the > element’s naturalWidth and naturalHeight properties should interact. > The css-images level 3 spec says: > > "The intrinsic height and width are derived f

Re: [whatwg] scrap the srcset attribute

On Mon, Mar 2, 2015 at 1:08 PM, Michael A. Peters wrote: > On 03/02/2015 09:47 AM, Tab Atkins Jr. wrote: >> This is much easier to write and to maintain > > Is it really? > > With a simple key=value pair, I can: > > $src = trim($node->getAttribute('src&#x

Re: [whatwg] scrap the srcset attribute

On Mon, Mar 2, 2015 at 8:46 AM, Michael A. Peters wrote: > Dear WHATWG, > > Scrap the srcset attribute. > > Traditionally in HTML, and in every instance of XML I have personally worked > with, an element's attribute is a key=value pair. > Okay the type attribute for source node in audio and video,

Re: [whatwg] "resize" events on elements

On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa wrote: >> On Feb 23, 2015, at 5:40 PM, Dean Jackson wrote: >> At the recent Houdini meeting there was a vague agreement between the >> browser engines on adding a way for elements to be notified when their size >> changes. We've run into a number of

Re: [whatwg] HTML tags.Panorama, Photo Sphere, Surround shots

On Sun, Nov 16, 2014 at 4:38 PM, Biju wrote: > New cameras/phone cameras comes with Panorama, Photo Sphere, Surround > shot options. But there is no standard way to display the image on a > webpage. Can WHATWG standardize it and provide HTML tags. > > > Photo Sphere https://www.google.com/maps/abo

Re: [whatwg] [hidden] attribute should not allow overrides via css

On Wed, Nov 5, 2014 at 5:07 PM, Bruno Racineux wrote: > Those two lines from spec [1] are in conflict: > > "Because this attribute is typically implemented using CSS, it's also > possible to override it using CSS" > > "if something is marked hidden, it is hidden from all presentations" > > The lat

Re: [whatwg] HTML has no definition / automated test suite

On Sat, Nov 1, 2014 at 7:18 AM, Stefan Reich wrote: > Hi WhatWG and friends! > > I am currently making an AI to create HTML. In the process, I discovered a > logical problem: HTML is not clearly defined. Not as far as I know anyway. > > A proper definition of HTML would include collections of samp

Re: [whatwg] Proposal: Write-only submittable form-associated controls.

On Wed, Oct 15, 2014 at 8:59 AM, Domenic Denicola wrote: > For the XSS attacker, couldn't they just use > `theInput.removeAttribute("writeonly"); alert(theInput.value);`? > > Or is this some kind of new "un-removable attribute"? Doesn't matter if it is or not - the attacker can still always just

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 8, 2014 at 10:54 AM, Olli Pettay wrote: > On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote: >> >> On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren >> wrote: >>> >>> On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola >>> wrote: >>

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren wrote: > On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. wrote: >> You keep ignoring the past "turns out we like using async errors for >> 'soft failures' of this kind, and have done it lots of times, and >>

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren wrote: > On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola > wrote: >> What I find interesting here is the claim that people find try/catch >> annoying or distasteful. > > I don't think you should need try/catch for a common failure case. > That i

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel wrote: > On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. wrote: >> >> The question is whether it's not natural to assume that *if the promise >> fulfills*, that means they got permission. This allows them to do things >

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 8, 2014 at 1:07 AM, Anne van Kesteren wrote: > On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. wrote: >> The question is whether it's not natural to assume that *if the promise >> fulfills*, that means they got permission. This allows them to do things >> l

Re: [whatwg] Notifications: making requestPermission() return a promise

On Oct 7, 2014 11:32 PM, "Anne van Kesteren" wrote: > > On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. wrote: > > On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren wrote: > >> On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola > >> wrote: > >>&g

Re: [whatwg] Notifications: making requestPermission() return a promise

On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren wrote: > On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola > wrote: >> So we should make a choice, as to whether we want developers to assume they >> will always get permission (in which case it should reject upon permission >> not being granted

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel wrote: > On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. wrote: >> I've never heard this opinion explicitly expressed, and it has never >> shown up in any API reviews of promise-using specs. It's directly >> contra

Re: [whatwg] Notifications: making requestPermission() return a promise

eir > values with .catch(), but exceptions are really the same thing as > «deal with rejections *later*, letting you execute a bunch of code on > the success path and only at the end saying "Oh, did something along > the line fail? Let me take care of that.".» Yeah, you'r

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 1, 2014 at 11:44 AM, Domenic Denicola wrote: > From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Tab Atkins > Jr. > >> This is actually kinda terrible. Promises make it *really easy* to deal >> with rejections *later*, letting you execute a

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 1, 2014 at 9:34 AM, Anne van Kesteren wrote: > On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. wrote: >> And I wouldn't expect someone loading a FontFace synchronously to use >> try/catch to deal with loading errors, either, because that's super >> ob

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren wrote: > On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. wrote: >> Wait, what? Anytime you request something, not getting it is >> exceptional. Not sure how you can make an argument otherwise. > > I would not expect a synchr

Re: [whatwg] Notifications: making requestPermission() return a promise

On Wed, Oct 1, 2014 at 9:06 AM, Anne van Kesteren wrote: > On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo wrote: >> One argument I came across for overloading requestPermission is the >> following: >> Promise.all([ Notification.requestPermission(), >> swRegistration.push.requestPermission() ]

Re: [whatwg] ARIA semantics of implied rows

On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien wrote: > On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren wrote: >> On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien >> wrote: >> > One issue is that the ARIA semantics for "implied rows" are not defined. >> >> I'm not sure I understand why ARI

Re: [whatwg] Notifications and service workers

On Thu, Sep 25, 2014 at 4:24 PM, Jonas Sicking wrote: >>> * Alternatively, maybe we could simply get rid of the "close" event >>> entirely. Does it have a use-case? >> >> Yeah: >> >> * User gets new chat message >> * Push message >> * Notification >> * User reads chat message but doesn't need to r

Re: [whatwg] Notifications and service workers

On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking wrote: > After having talked to our web developers, and having talked to Olli, > I've come to the following conclusions: > > * We should consider the case of persistent notifications separate > from notifications that automatically close when a page g

Re: [whatwg] CanvasRenderingContext2D and CSS Image filters

On Thu, Sep 18, 2014 at 11:15 AM, Vivek Galatage wrote: > Hi all, > > I just wrote a test case which involves applying a CSS image filter > (--webkit-filter or filter) using a grayscale filter. > http://jsfiddle.net/whyn9075/ > > With this image element, I used a canvas rendering context 2d to dra

Re: [whatwg] Canonical Image and Color

On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren wrote: > On Mon, Aug 25, 2014 at 8:59 PM, Mike wrote: >> 2) There is already a couple of standards or quasi-standads: >> - favicons (most promising seems to be the increasing of their size and >> svg support) >> - apple-touch-icon used b

Re: [whatwg] Canonical Image and Color

On Tue, Aug 26, 2014 at 4:59 AM, Mike wrote: > Hey Folks, > Let’s get back to this subject as it seems there is still no solution. > Recently we - Yandex.Browser - discussed with Opera if there could be a > standard for page icons (let’s call it so) on NewTabPage that replace small > screenshot

Re: [whatwg] `brand-color` meta extension

On Wed, Aug 20, 2014 at 12:39 PM, Mark Callow wrote: > On 2014/06/26 12:58, Marcos Caceres wrote: >> I would be in favor of this. It would be good to support the legacy content >> as its use on the Web is significant. Search I did back in Oct 2013 found >> these proprietary tags appeared on some

Re: [whatwg] Proposal: Wake Lock API

On Tue, Aug 19, 2014 at 1:44 PM, Marcos Caceres wrote: > On August 19, 2014 at 4:39:03 PM, Tab Atkins Jr. (jackalm...@gmail.com) wrote: >> > Why is isHeld still used here? You don't need it to avoid squashing >> someone else's lock with this design, and several peo

Re: [whatwg] Proposal: Wake Lock API

On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres wrote: > On August 19, 2014 at 2:08:04 PM, Jonas Sicking (jo...@sicking.cc) wrote: >> > > How would you handle feature detection with this design? >> >> This is a good question. I don't have a better solution than adding >> separate DisplayWakeLock()

Re: [whatwg] Proposal: Wake Lock API

On Tue, Aug 19, 2014 at 11:07 AM, Jonas Sicking wrote: > On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri wrote: >> How would you handle feature detection with this design? > > This is a good question. I don't have a better solution than adding > separate DisplayWakeLock() and SystemWakeLock() cla

Re: [whatwg] Proposal: Wake Lock API

On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri wrote: > On Tue, 19 Aug 2014, at 04:54, Jonas Sicking wrote: >> Note that in the API that I'm proposing, there is no way to >> accidentally rely on GC behavior. If a WakeLock object is GCed before >> it has been release()ed, then the lock is held ind

Re: [whatwg] Preventing wake lock leaks with DOM nodes

On Mon, Aug 18, 2014 at 5:10 PM, Domenic Denicola wrote: > In general I feel this thread has taken a turn for the complex. Why don't we > just do what other platforms do, and provide a simple global request/release > mechanism (or toggleable Boolean property!), which developers can build on > t

Re: [whatwg] Preventing wake lock leaks with DOM nodes

On Mon, Aug 18, 2014 at 4:21 PM, Kornel Lesiński wrote: > My biggest concern with the WakeLock API is that it's easy to forget (or > fail) to release the lock. > > It's not a problem with the API per se, but a programming problem in general: > resource management in non-trivial programs is hard.

Re: [whatwg] Proposal: Wake Lock API

On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp wrote: > Jonas Sicking writes: >> On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri wrote: >>> On Thu, 14 Aug 2014, at 11:00, Jonas Sicking wrote: I am however more worried about that only having a request() and a release() function m

Re: [whatwg] Question on server side api

On Aug 4, 2014 7:08 PM, "L2L 2L" wrote: > > ... Here's a question that will get a huh? > > Do the browser have an api that is use This is a stupid question Do the browser have an api that I can use to preform --I'm still a novice-- simple server side action? No. Browsers have no control

Re: [whatwg] Better DOM hooks for polyfilling CSS properties?

[This discussion belongs on the www-st...@w3.org list, not whatwg. I'll give a perfunctory answer here, but will not follow up. Please start a thread on www-style if you wish to discuss this further.] On Jul 10, 2014 2:39 PM, "Brian Blakely" wrote: > > Problem > === > > It's difficult to know whe

Re: [whatwg] Questions about the Fetch API

On Tue, Jul 8, 2014 at 11:35 AM, Juan Ignacio Dopazo wrote: > - And more importantly, why does fetch() return a Promise instead > of a Response? Because you aren't allowed to do network fetches sync. (And if you have an async action, returning a Promise for its result is the idiomatic way to do

Re: [whatwg] brand-color meta extension

On Mon, Jun 30, 2014 at 9:23 AM, Tao Bai wrote: > Shall we enforce brand-color in head elements? it could make the > brand-color loaded ASAP, just like the favicon. Not needed, imo. If you put it in the head (or at least, early in the body), it'll get read early; if you put it late, it'll be rea

Re: [whatwg] SVG cloning elements from HTML5

On Fri, Jun 27, 2014 at 2:11 PM, David Carlisle wrote: > Who do you mean by "we" in the above (css wg, svg wg, whatwg here) not that > it matters really but if > I need to go and ask the Math WG to coordinate with someone I want to be > able to say who that is:-) Me, mostly, but CSSWG if you need

Re: [whatwg] SVG cloning elements from HTML5

On Fri, Jun 27, 2014 at 2:16 AM, David Carlisle wrote: > If the parser is changing here could we also change it so that HTML elements > don't auto close math > for which there was also only ever fragile justification. Yes, no reason to exclude math here. It should be consistent. > It would make

Re: [whatwg] brand-color meta extension

On Thu, Jun 26, 2014 at 1:40 PM, Anne van Kesteren wrote: > On Thu, Jun 26, 2014 at 10:32 PM, Tab Atkins Jr. wrote: >> The spec does not suggest that it would be a simple color; it says to >> allow any CSS color. "simple color" in HTML is solely a 6-digit hex >> c

Re: [whatwg] brand-color meta extension

On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens wrote: > On 26 Jun 2014, at 22:24, Mathias Bynens wrote: > >> Interesting to see this would be only the second HTML attribute value to get >> parsed as a simple color >> (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsynt

Re: [whatwg] brand-color meta extension

On Thu, Jun 26, 2014 at 1:24 PM, Mathias Bynens wrote: > Interesting to see this would be only the second HTML attribute value to get > parsed as a simple color > (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) > rather than a legacy color (t

Re: [whatwg] Proposal: defining script as

On Thu, Jun 26, 2014 at 12:09 PM, Boris Zbarsky wrote: > On 6/26/14, 2:57 PM, Тимофей Маринин wrote: >> >> Do you mean "if style src were supported"? > > No, I mean what I said. But looks like

Re: [whatwg] SVG cloning elements from HTML5

On Thu, Jun 26, 2014 at 10:40 AM, Chris Lilley wrote: >> Better integration of HTML and SVG (and blocking any further >> element copying beyond the four existing elements) is really >> important. > > Much more important than maintaining rendering of someone's "tried this > and it didn't do anythi

Re: [whatwg] `brand-color` meta extension

On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. wrote: > This feature has been developed in the past under multiple proprietary > names, such as "mapplication-navbutton-color" for Internet Explorer > and "apple-mobile-web-app-status-bar-style" for Mobile Safar

Re: [whatwg] `brand-color` meta extension

On Thu, Jun 26, 2014 at 10:35 AM, Marcos Caceres wrote: > Folks at Mozilla and Google would like to standardize the `brand-color` meta > extension. The `brand-color` keyword has been added to the MetaExtensions > WHATWG wiki and a rough spec is below (prepared by some folks at Google). > > # Ove

Re: [whatwg] SVG cloning elements from HTML5

On Thu, Jun 26, 2014 at 9:44 AM, Anne van Kesteren wrote: > On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. wrote: >> (The current proposal would place all the direct HTML children of SVG >> elements on top of each other, similar to abspos, but grandchildren >> would rend

Re: [whatwg] SVG cloning elements from HTML5

On Thu, Jun 26, 2014 at 9:11 AM, Ian Hickson wrote: > On Tue, 24 Jun 2014, Robert O'Callahan wrote: >> >> >> >> >> >> the elements "s" and "i" are put in the HTML namespace already. > > As siblings of the element, though, not descendants. > > This was required to get some level of compatibili

Re: [whatwg] SVG cloning elements from HTML5

[plain-text email, please. HTML emails rarely survive plain-text-ification unscathed.] On Mon, Jun 23, 2014 at 11:35 PM, Gavin Kistner wrote: > On 24 Jun 2014, at 05:25, Robert O'Callahan wrote: >> On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. >> wrote: >>> >

Re: [whatwg] SVG cloning elements from HTML5

On Mon, Jun 23, 2014 at 9:35 PM, Dirk Schulze wrote: > On Jun 24, 2014, at 5:25 AM, Robert O'Callahan wrote: >> On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. >> wrote: >>> Yes, increasing the set of name-alikes between html and svg is absolutely >>&

Re: [whatwg] SVG cloning elements from HTML5

On Jun 18, 2014 6:00 AM, "Robert O'Callahan" wrote: > > I just discovered > https://svgwg.org/svg2-draft/embedded.html > This looks very problematic. It ties SVG and HTML5 together in > uncomfortable ways. For example, SVGIframeElement as specced has two > "width" attributes. It's unclear how to k

Re: [whatwg] Proposal: Inline pronounce element (Tab Atkins Jr.)

On Thu, Jun 5, 2014 at 11:29 AM, Nils Dagsson Moskopp wrote: > Brett Zamir writes: > >> On 6/5/2014 3:05 AM, whatwg-requ...@lists.whatwg.org wrote: >>> >>> On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris >>> wrote: Hello, With existing assistive technology such as screen readers, an

Re: [whatwg] Proposal: Inline pronounce element

On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris wrote: > Hello, > > With existing assistive technology such as screen readers, and more > recently the pervasiveness of new technologies such as Siri and Google > Now to name two examples, I have been thinking about the > appropriateness and potential

Re: [whatwg] hidden attribute useless with display: flex?

On Wed, Apr 30, 2014 at 2:32 PM, Ian Hickson wrote: > On Wed, 30 Apr 2014, Anne van Kesteren wrote: >> We could change the specification to use display-box instead. That might >> work. > > Would that break sites that are intentionally replacing the styling for > hidden="" from 'display:none' to 'o

Re: [whatwg] hidden attribute useless with display: flex?

On Wed, Apr 30, 2014 at 7:32 AM, Glenn Maynard wrote: > It's too bad that display-box also has multiple uses--it doesn't only > display or hide the content, it has a third "contents" mode. That means > the same problem would happen as soon as you set "display-box: contents" on > something--it wou

Re: [whatwg] summary/details - proposal

On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner wrote: > avoiding unnecessary recourse to web component use is a reasonable and > expected goal - built in vs bolt on accessibility is better. Having to use > a web component to overcome the inability to make a html control usable > without relying on

Re: [whatwg] new constructor method for Path2D

On Mon, Mar 10, 2014 at 11:38 AM, Justin Novosad wrote: > On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier wrote: >> On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio > >wrote: >> > What part is slow, the decoding and re-encoding, or is just always the >> > encoding step >> > that is slow? >> >> It's d

Re: [whatwg] Proposal: requestBackgroundProcessing()

On Thu, Feb 20, 2014 at 8:23 AM, Ashley Gullen wrote: > Isn't setTimeout also clamped to 1s in the background? This alone would add > so much latency as to effectively hang the game anyway. Ah, I wasn't sure if anyone actually did that; I just tested in Chrome, though, and it definitely does. Al

  1   2   3   4   5   6   7   8   9   10   >