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

[Tab Atkins Jr.]

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.
>  then text with line brakes and proportional font using CSS styling.
>
> I wish it to be standardized, so if no recommendation exist, I suggest
> following tags.
>  - With left/right intend from margin, and zero top/bottom
> margin (almost  BLOCKQUOTE).
>  - With top/bottom margin, but zero left/right margin (similar to  
> ).
>  this is for LINE, single character tag name to replace use of BR.
> Content in tag should not word wrap, instead it should continue
> right side like contents in  tag.
>
> We also need a set of tags for MUSIC LYRICS, with VERSE, CHORUS,
> tag/attribute to mark repetition. As well as other tags/attributes
> which music community thinks will be needed.

Poems and lyrics are, generally, just text that has significant
line-breaks. Thus,  and  are the correct markup for them.

For poetry that plays around with spacing and alignment (and thus has
significant whitespace),  is the correct markup for it.

To add anything new to support these, head over to
 and run thru the
questionaire there; the bar for new additions to HTML is relatively
high. In particular, merely wanting to encode more semantics into a
document is often not worthwhile - in general, semantics are only
useful insofar as they help machines understand the document (so they
can help humans more effectively, such as screenreaders, search engine
spiders, etc.). You'll have to answer to why this level of additional
semantics for poetry is valuable in this way, and how it improves over
the current situation in tools that actually exist (or make a *very*
convincing argument that the current lack of semantics *prevents* a
useful tool from existing, and it's likely that the tool will develop
on its own after this is added).

~TJ

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

[Tab Atkins Jr.]

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 require any thought about interactions?
>>
>>
>> You get two flex items, because being in a flex container overrides the
>> outer display type of an element:
>>   https://www.w3.org/TR/css-flexbox-1/#flex-items
>>
>> In other words, the run-in/inline/block distinction is ignored within a
>> flex container.
>
>
> Sure, but my point wasn't whether the behavior is _defined_.  It's that
> defining it requires thinking about the various cases, and having run-in
> makes for more cases to think about.

Not really.  The Flexbox text was written without any consideration of
run-ins.  It nevertheless handles run-ins correctly (they get
blockified and become flex items).  Grid should work the same way, as
will any future layout modes we define.  (v1 of Custom Layout
blockifies children in the same way, or at least is meant to; it's
been too long since I reviewed that part of the spec.)

~TJ

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

[Tab Atkins Jr.]

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 replaced
>>> by its (DOM) children.
>>
>>
>> That contradicts what fantasai claimed the spec says.
>>
>> Which brings me back to my claim that the spec is not clear enough: one of
>> you two is wrong, which isn't really a situation that should arise with a
>> clear spec.
>
> I have tried to clarify this in https://github.com/whatwg/html/pull/1799.

Looks like it's clarified now - the CSS side of things was very clear,
it was HTML that wasn't clear about which "child" concept it was
using. ^_^

~TJ

Re: [whatwg] proposal for new inputmode: digits

[Tab Atkins Jr.]

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?
>>>
>>
>> Please re-read the original email of the thread.
>>
>> I am arguing that *neither*
>> 
>> nor
>> 
>> are correct.
>>
>> While I could understand a keyboard which only allows "allowed tokens" this
>> is entirely infeasible given modern regular expressions are Turing
>> complete. In fact, they are infeasible even as DFAs considering valid
>> values depend on future input.
>
> I massively doubt that a “regular” expression could be turing complete.

Real regexps (per the dictionary definition of them) are not TC,
they're regular.  Perl regexps are TC, due to additions.  Other
languages' regexps may or may not be TC, depending on how
Perl-compatible they are, but most of them recognize more than regular
languages.

That all said, this is irrelevant.  Recognizing very simple patterns
like "just a \d or [0-9] with repetition" has nothing to do with
TCness or future-input prediction.

>> There is room for a "digits only" inputmode which is *already* a mode
>> supported by some mobile browsers. I'd only like to make this explicit and
>> non-magical.
>
> Could you qualify the attribute “magical” ?

Inferring from the pattern that a text input will be digits-only, and
altering the UI to accommodate that, is "magical" because it's not
specified - if there was a line in the spec that talked about
recognizing certain patterns, it might be different.  We already have
a feature for hinting what kind of input is expected - the inputmode
attribute.  It even has a "numeric" value, but that's for entering
actual numbers and per-spec allows for thousands  separator,
plus/minus signs, etc.  Eitan is asking for an inputmode specialized
to "digit strings" specifically, where the only allowed characters are
those recognized by /\d*/, so the intent can be made explicit, rather
than just hoping that browsers present a reasonable UI.

This seems reasonable to me, particularly since browsers already
present the desired UI in some cases.

~TJ

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

[Tab Atkins Jr.]

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 flag
turned on (so we actually parse , rather than it being
parsed as an unknown element), you'll see a ton of crap overlaying the
page from the s.  I'm leaning pretty heavily toward this being a
coincidental name collision; that is, it looks like they're
intentionally unknown elements that happen to be named
/; the markup has no relation whatsoever to what is
specced.

~TJ

Re: [whatwg] How to add html5 browser support

[Tab Atkins Jr.]

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.

~TJ

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

[Tab Atkins Jr.]

On Sat, Aug 29, 2015 at 12:51 AM, Hugh Guiney hugh.gui...@gmail.com 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 SVG defs and other metadata-related elements in HTML's head
 seems like an obvious choice from a semantic standpoint. But it is currently
 illegal in the HTML spec because SVG does not distinguish between embedded
 and metadata content models for its elements, which Hixie has requested so
 that the HTML spec can simply point to the SVG spec's definitions. (Please
 see quoted text.)

 Again, is this something the SVG WG is willing to do?

This isn't even something for the SVGWG to decide; it's simply
impossible to add new elements to HTML's head.  head autocloses
when it sees any element that's not title, meta, link, script,
or style, and people depend on this behavior - there's definitely
pages out there where an svg element is the first content and needs
to be displayed.

Just put a defs-only svg in the body.  Its location doesn't
actually matter, it's fine.

~TJ

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

[Tab Atkins Jr.]

On Wed, Jul 8, 2015 at 12:12 PM, Rick Byers rby...@chromium.org 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 in particular) being by
 far the biggest source of scroll jank.

 I've been talking about this problem off-and-on for several years with
 various folks including the Pointer Events Working Group, engineers of
 other browser vendors, and engineers working on popular libraries that are
 a source of such scroll-blocking event handlers (eg. Google Ads and
 Google Analytics).

 I've now written a relatively formal (but still sloppy by W3C standards)
 concrete spec for extending the DOM event model
 http://rbyers.github.io/EventListenerOptions/EventListenerOptions.html to
 address this problem and would like to solicit feedback.  It's probably
 most constructive to discuss specific issues on GitHub
 https://github.com/RByers/EventListenerOptions/issues, but I'd appreciate
 any high-level feedback here by e-mail too.  Please feel free to submit
 pull requests for eg. editorial improvements.

 Once there's a bit more consensus on the API shape, I plan to write a
 polyfill and tests and then begin a prototype implementation in Chromium.
 We have some initial evidence to believe that this (in partnership with a
 few key library authors) can make a substantial improvement to the user
 experience on mobile.  I hope to be able to share more concrete data on the
 real-world performance impact, but there's obviously a chicken and egg
 problem here.

I like it!  I appreciate in general the upgrade of the third
addEventListener() argument from a boolean to an options bag, as that
was a really annoying wart in the API.  Makes specifying capture more
readable.

The new mayCapture argument makes a lot of sense, too.  It's very
frustrating having to deoptimize scrolling and similar things just
because the author *might* cancel the scroll; indicating that you
definitely won't, so we can keep it on the optimized path, is great.

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

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

 We support full CSS colors. Though, we ignore the alpha component.

Cool.  When are we going to see a spec for this?  ^_^

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Jun 26, 2015 14:30, Edward O'Connor eocon...@apple.com wrote:

 Hi Tab,

 You wrote:

  Sounds acceptable to me. What's the grammar of color=''? Just hex,
  or full CSS color? (Either is fine with me.)
 
  We support full CSS colors. Though, we ignore the alpha component.
 
  Cool. When are we going to see a spec for this? ^_^

 Well, typically what happens is people talk through various options on
 this mailing list and then Ian specs something out when he catches up on
 the thread. But you already knew that. :)

I also happen to have experience with just writing the spec myself, as you
know from both picture and theme-color, so I was hoping y'all'd do the
same. 

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak m...@apple.com wrote:
 To close the loop on this, we will change to link rel=mask-icon 
 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 override seems useful. So for now we'll 
 implement explicit color and we'll consider automatic color picking based on 
 the SVG as a fallback when the color is missing as a future extension.

 Please let me know if anyone disagrees with this approach.

Sounds acceptable to me.  What's the grammar of color=''?  Just hex,
or full CSS color?  (Either is fine with me.)

~TJ

Re: [whatwg] IPv4 parsing

[Tab Atkins Jr.]

On Wed, Jun 24, 2015 at 7:21 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com 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] IPv4 parsing

[Tab Atkins Jr.]

On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com 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 spec this in detail, please.

~TJ

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

[Tab Atkins Jr.]

On Thu, Jun 18, 2015 at 10:35 AM, Edward O'Connor eocon...@apple.com wrote:
 On the other hand, link rel=mask-icon color=darkslategray seems
 like it should Just Work™.

 I guess we could add support for named colors to input type=color
 too.

 Offhand I think that's a good idea. Probably won't round-trip through
 typical color picker implementations, but that doesn't seem like much of
 a problem to me.

 What do others think?

Just hex, or all CSS colors.  No sense going halfway here.  As you
note, they won't roundtrip, but if we're okay with that, then allowing
hsl() makes exactly as much sense as allowing cornflowerblue.

~TJ

Re: [whatwg] Shared workers with worker parents

[Tab Atkins Jr.]

On Fri, Jun 19, 2015 at 3:55 PM, James Burke jrbu...@gmail.com 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 also can trigger a sync, to use the
 same Shared Worker to efficiently coordinate the network/database
 work.

 There are more details on the use case[1], but the main spec issue:
 currently the Shared Worker part of the spec[2] only specifies
 Documents as a parent that can keep a Shared Worker alive.

 Would it be possible to change this to also allow any type of Worker
 as a parent to a Shared Worker that can keep a Shared Worker alive?

 Is bug 28504[3] enough to track this change, or are there other things
 to line up before considering the change?

 Thanks for the insight,
 James

 [1] https://github.com/slightlyoff/ServiceWorker/issues/678
 [2] https://html.spec.whatwg.org/multipage/workers.html#dom-sharedworker
 [3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=28504

How can a ServiceWorker keep a SharedWorker alive, when a
ServiceWorker does not, itself, have any lifetime guarantees?  In
fact, it's virtually guaranteed to be shut down regularly.

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 9:49 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Jun 16, 2015 at 10:42 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Before we start bikeshedding, can you commit to actually changing your
 implementation?  Safari has already shipped with the exact proposal
 given in this thread; if you're seeking a rubberstamp rather than a
 collab, say so.

 Maciej already clarified this, no? They're perfectly happy to change
 this before Safari 9 ships, provided, I'm guessing, that we settle
 this somewhat quickly.

Yup, I missed that part of Maciej's email; I just did a quick skim of
the rest of the thread after reading Ted's OP.

Sounds good, then.

~TJ

Re: [whatwg] Icon mask and theme color

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 11:51 PM, Smylers smyl...@stripey.com 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
 unstable to changes in the icon if it’s actually multi-color.

 No, but colour-averaging would only be a fallback to get _some_ colour
 in the situation where the developer failed to follow guidelines and put
 multiple colours in their mask image.

 Again, consider Twitter: if they have an icon which already is a solid
 shape of the correct colour (so it can be used as a colour icon, too),
 why should they have to specify that colour a second time in their HTML?
 You already know what the colour is, from the icon itself.

*If* we detect the color from the icon (which I don't think is a bad
idea), using dominant color or first color (as Maciej argued) does
seem better than color averaging.  Averaging seems like it would
rarely produce a reasonable color in any multi-color icon, as it won't
produce any of the actual brand colors (and how to average is an
open question; many answers, like the obvious naive RGB averaging,
give terrible results in lots of cases).  Dominant/first color would
at least give you one of the brand colors.

And for single-color icons, dominant/first gives the same results as
averaging, so it's fine there.

~TJ

Re: [whatwg] Icon mask and theme color

[Tab Atkins Jr.]

On Wed, Jun 17, 2015 at 5:16 PM, Karl Dubost k...@la-grange.net wrote:
 Tab,

 (summary: let's put the information inside the SVG file, more below)

 Le 18 juin 2015 à 08:41, Tab Atkins Jr. jackalm...@gmail.com a écrit :
 better than color averaging.  Averaging seems like it would
 rarely produce a reasonable color in any multi-color icon,

 And we will certainly create rage into Marketing/Communications departments.

 Dominant/first color would at least give you one of the brand colors.

 Better, not necessary the best.
 Because of the following reasons:

 1. these icons are specific to the mask system.
 2. SVG format is mandatory [1]

 Why not
 * giving more power to the designers,
 * respecting the people in charge of branding,
 * and reducing the source of confusions (people managing the markup != people 
 designing icons)

 by including **inside the SVG** the color requirements.

Because having it be determined automatically is simpler and more
likely to give good results broadly.  (This isn't an argument against
having it optionally determined by a specific metadata, of course,
just an argument that *in the absence of more specific information* we
should default to something reasonable from the outside.)

 metadata
   iconmask:iconmask xmlns:iconmask=http://www.w3.org/ns/@@@something@@;
   iconmask:meta name=primary color=#bada55 /
   iconmask:meta name=secondary color=#505 #123456 /
   /iconmask:iconmask
 /metadata

 (better syntax, naming, unicorns are welcome, but that's not currently the 
 point)

 [1]: 
 https://developer.apple.com/library/prerelease/mac/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html#//apple_ref/doc/uid/TP40014305-CH9-SW20

SVGWG isn't adding any new namespaces to SVG.  We've discussed in the
WG just adding a meta name content element to SVG; that would be
sufficient for this kind of thing.

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 2:36 PM, Elliott Sprehn espr...@chromium.org wrote:
 On Tue, Jun 16, 2015 at 2:33 PM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
 On Tue, Jun 16, 2015 at 2:25 PM, Elliott Sprehn espr...@chromium.org
 wrote:
  On Tue, Jun 16, 2015 at 2:22 PM, Tab Atkins Jr. jackalm...@gmail.com
  wrote:
  On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn espr...@chromium.org
  wrote:
   sizes is a generic feature that's available for all image resources.
 
  No it's not; img sizes and link sizes are completely unrelated.
 
  :( That's really confusing:
 
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes

 Non-global attributes aren't global. Who knew. ^_^

 Well, two elements that both load image resources and both have an attribute
 named sizes that do different things isn't very good developer ergonomics.
 href isn't global either, but I'd be sad if we added a new element where it
 was interpreted as something besides a url.

Yeah, you're not wrong.  I simply didn't remember that link sizes
existed when I designed img sizes.  If we could redo that, I might
have chosen a different name.

~TJ

Re: [whatwg] Icon mask and theme color

[Tab Atkins Jr.]

On Mon, Jun 15, 2015 at 12:00 PM, Maciej Stachowiak m...@apple.com 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 don't think we need anything new for colors
here.  UAs SHOULD look at the lightness of the theme-color and make
adjustments as appropriate.  (Tho only if necessary - Twitter blue,
for example, should stay unless it's really bad. Icons don't need to
meet the same a11y contrast guidelines as text, I wouldn't think,
giving you a lot of latitude to keep the specified color exactly in
most circumstances.)

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 2:07 PM, Elliott Sprehn espr...@chromium.org wrote:
 sizes is a generic feature that's available for all image resources.

No it's not; img sizes and link sizes are completely unrelated.

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Tue, Jun 16, 2015 at 1:51 PM, Edward O'Connor eocon...@apple.com 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 not clear to me why link rel=icon mask
 wouldn't make sense, but link rel=icon sizes does. They are both
 useful advisory hints that help UAs avoid redundant resource loads.

sizes really is an advisory hint; if you don't understand it and
just download one of the icons, at worst you'll get a version that
needs to be scaled up or down.  Accidentally displaying a mask
version of the favicon can give substantially worse results; the
design tradeoffs made for mask icons can be substantially different
than those for favicons, and result in a completely unsuitable icon
(particularly if rendered in solid black, as is currently
recommended).

Note the WHATWG thread from two days ago about link rel=icon mask
already being seen in the wild and having precisely this problem,
where the simplest conclusion appears to be *specifically ignoring the
mask links*. 
https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Jun/0011.html

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

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

 No it's not; img sizes and link sizes are completely unrelated.


 :( That's really confusing:
 https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-sizes

Non-global attributes aren't global. Who knew. ^_^

 In any case, I don't think adding a boolean mask attribute to link
 specific to the icon type makes sense.

Agreed, for the reasons stated previously by myself and others.

~TJ

Re: [whatwg] A mask= advisory flag for link rel=icon

[Tab Atkins Jr.]

On Mon, Jun 15, 2015 at 10:37 AM, Edward O'Connor eocon...@apple.com wrote:
 Authors would provide a mask icon like so:

 link rel=icon href=mask.svg mask
[...]
 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 icon that are interesting: it's monochrome
 (and can be tinted to fit a theme), it's suitable for use as a mask,
 it's a simple/minimal/reduced representation of the site or app. We
 could go with a monochrome attribute, a mask attribute, or some other
 option. Out of these I most like an attribute named mask. It's shorter,
 for one. But I don't strongly prefer it and I'm sure someone else will
 come up with something way better.

Before we start bikeshedding, can you commit to actually changing your
implementation?  Safari has already shipped with the exact proposal
given in this thread; if you're seeking a rubberstamp rather than a
collab, say so.

In the spirit of bikeshedding, Justin Dolske seems to have the right
idea.  mask or icon-mask or something as a new rel value that
indicates a file to be used as a theme-color-filled mask works better
within the existing ecosystem.  In particular, naive processors that
understand rel=icon but not mask (aka every browser on the market
today besides latest Safari) won't do stupid things, like use the mask
as an icon directly.

 There’s no technological enforcement that the SVG only uses the color
 black. We will interpret it as a mask in the same way as the SVG ‘mask’
 element, which effectively combines the luminance with the alpha channel.
 Effectively, this means that other colors will end up partly transparent,
 so using other colors will probably do something weird, but nothing
 prevents authors from doing that afaik.

 The reason for treating the icon as a mask is that we want to enforce
 having a monochrome shape, specifically for our pinned tabs feature.

The svg mask element has a switch for choosing between luminance and
alpha masking; I think using alpha masking instead seems like a pretty
clear win.  It makes the color irrelevant, making it more likely that
the plain icon is appropriate to use for a mask as well, and there's
no difference in behavior if you're using opaque colors.  (No
difference in functionality overall, either; you just achieve
partial-transparency with alpha rather than color.)

~TJ

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

[Tab Atkins Jr.]

On Thu, May 7, 2015 at 10:42 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, May 7, 2015 at 11:23 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Well, beyond the existing conflicts of style, script, and a.
 (font too, but that's dropped from SVG2, so who cares.)

 textArea is out too?

textArea was never in - it was an SVG Tiny element, and thus never
appeared in any web-compatible version of SVG.

 With respect to case-insensitive matching, I don't really understand
 why we simultaneously want to make these rather trivial changes to SVG
 while at the same time move to constructors for creating elements,
 which is even stricter than createElementNS() (literal has to be
 correctly spelled or you get an exception). If we want to move to a
 world where people write

   new SVGRectElement

 why would we even bother making

   document.createElement(RECT)

 work?

It's not about that, it's about making, say, lineargradient {...}
work, because you can case selectors any which way for HTML, and it's
confusing that you can't for SVG.

(And I'm still not convinced on constructors, anyway - they're so
verbose! And we would to have to fix so many of them!)

 Same for CSS, the majority of CSS already uses type selectors where
 the case matches up with the HTML. Is complicating it really worth it?
 We should bring the languages closer, but we shouldn't put the
 mistakes we made with HTML into SVG.

I don't think ascii case-insensitivity is a mistake here.

~TJ

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

[Tab Atkins Jr.]

On Fri, May 8, 2015 at 10:13 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, May 8, 2015 at 7:09 PM, Tab Atkins Jr. jackalm...@gmail.com 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 have it it's sticking out as sore thumb with a
 dozen subtleties attached.

It's all over CSS (every single language-defined keyword is CI), and
all over a bunch of HTML. Whether you think it's a mistake or not,
it's *common*, and having some tags use it while others don't is
confusing.

~TJ

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

[Tab Atkins Jr.]

On Fri, May 8, 2015 at 9:09 AM, Boris Zbarsky bzbar...@mit.edu 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.

Looks like the patch that recently landed *did* exactly this - it
would do a string-walk when matching tags/attributes against SVG
elements. It was indeed slower, but it was just for SVG, and wasn't a
huge hit.

But then Elliot realized that we keep around a second pointer for the
uppercased tagname anyway (some of the tagname accessors return
uppercase for HTML), so he just rewrote it to store the proper casing
there instead, for SVG elements. ^_^  Now it's no extra memory or
runtime cost.

~TJ

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

[Tab Atkins Jr.]

On Thu, May 7, 2015 at 2:11 PM, Elliott Sprehn espr...@chromium.org wrote:
 On Thu, May 7, 2015 at 2:09 PM, Boris Zbarsky bzbar...@mit.edu 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 created with mixed casing, or
 imported from an XML document, might not match a lowercase tagname
 selector, but SVG written in HTML will.

 Hmm.  The main problem here is for scripts that create SVG elements in an
 HTML document, since those have to use createElementNS and pass the
 mixed-case names (e.g. for foreignObject).

 One idea could be to make createElement() return SVG elements for svg tag
 names embedded in HTML.

 Neither spec is ever going to have a conflicting tag name.

Well, beyond the existing conflicts of style, script, and a.
(font too, but that's dropped from SVG2, so who cares.)  But the
SVGWG already resolved to allow HTML elements inside of SVG, so they
don't have to, say, add an svg:video element.  (I'm on the hook to
define the SVG layout model in terms of the CSS box model, which is
trivial, but I haven't had the time to do it yet.)

But yeah, the SVGWG resolved to never add new conflicts, and I assume
HTML is similarly okay with not adding tagnames that SVG has already
claimed.

~TJ

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

[Tab Atkins Jr.]

On Thu, May 7, 2015 at 8:26 AM, Boris Zbarsky bzbar...@mit.edu wrote:
 Note that at least for textArea 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 big deal.

 You mean case-sensitively in the implementation? Type selectors are
 case-insensitive for html elements.


 style
   * { color: green }
   foo { color: red }
 /style
 script
   var e = document.createElementNS(http://www.w3.org/1999/xhtml;, Foo);
   e.textContent = Is this red?;
   document.documentElement.appendChild(e);
 script

 If the matching were actually case-insensitive, the text would be red. It's
 not.

 The WebKit implementation represents each type selector with two
 strings, one lowered and one with original case, when the type
 selector is not lower-cased in the source. What does Gecko do?


 Exactly the same thing.

 To always match type selectors case-insensitively in html documents.


 I don't think that's acceptable to at least Gecko from a performance
 standpoint.  Not if it means we have to end up with red text in my testcase
 above.

I believe the SVGWG is fine with a parsing-based approach, exactly
like what HTML does.  An SVG element created with mixed casing, or
imported from an XML document, might not match a lowercase tagname
selector, but SVG written in HTML will.

~TJ

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

[Tab Atkins Jr.]

On Thu, May 7, 2015 at 4:16 AM, Rune Lillesveen r...@opera.com 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 the prose:

 !DOCTYPE html
 style
 foreignObject { color: red }
 foreignobject { color: green }
 /style
 foreignOBJECTMatches both rules. Case-insensitive match. Is
 green./foreignOBJECT
 svg
 FOREIGNobjectMatches the first rule because the parser
 normalizes to the camelCased form as per spec. Is red./FOREIGNobject
 /svg

 This adds an implementation complexity to type selector matching.
 What's the rationale for matching the selector case-sensitively in the
 svg case?

 I'm sorry if I've missed previous discussions. I did see a few really
 long mails and threads about svg in html on this list, but weren't
 able to find the resolution for this in reasonable time.

 Should we change the spec in this regard?

 I did have a correct implementation for Blink, but was asked in the
 review [2] to match insensitively for non-html elements in html
 documents due to the complexity.


 [1] https://html.spec.whatwg.org/multipage/scripting.html#selectors
 [2] https://codereview.chromium.org/1099963003

The SVGWG just resolved to allow SVG elements and attributes to be
matched case-insensitively, like HTML.  We also resolved to try and
find a method to make parsing SVG case-insensitive in general.

For the latter, we're specifically interested in doing so when SVG is
embedded in HTML, and also having some way to indicate that a
standalone SVG should parse using similar rules (either a modification
of the HTML parser, or Anne's XML5 work, or something similar).  When
written in the XML syntax, it's fine for it to continue being
case-sensitive as it is today.

I presume this means that we'd start returning lowercased tagnames for
element in SVG-in-HTML.  Do we think that's a compat risk?  If so,
perhaps we can do something smaller, like having the
localName/nodeName/tagname attributes be getters that camelcase those
tagnames, but internally they're lowercased by the parser.  (It looks
like localName and tagname already differ in casing in HTML, so either
we store two strings, or we do the casing transformation in a getter
already.)

~TJ

Re: [whatwg] EventSource and data URLs

[Tab Atkins Jr.]

On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl 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 frustrating when data: urls don't work in various places;
they're an invaluable debugging tool, at minimum.  They should
generally be treated as the same security level as the page, no?

~TJ

Re: [whatwg] EventSource and data URLs

[Tab Atkins Jr.]

On Mon, Apr 27, 2015 at 3:58 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Mon, Apr 27, 2015 at 2:20 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 On Mon, Apr 27, 2015 at 7:00 AM, Anne van Kesteren ann...@annevk.nl 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 frustrating when data: urls don't work in various places;
 they're an invaluable debugging tool, at minimum.  They should
 generally be treated as the same security level as the page, no?

 There's definitely exceptions to this. For example chrome doesn't run
 a iframe src=data:... with the same origin as its parent. For IMHO
 good reasons since it's a potential XSS vector if a website accepts
 URLs from third parties and render them inside a child iframe.

 The same problem exists with accepting data: URLs in new Worker(...).

 So no, I don't think it should be treated as the same security level
 as the page.

 For data-loading APIs, rather than script-running APIs, I see less of
 such risk though.

Yeah, I can see the potential risks for script-running APIs, but this
is definitely a data-loading API. ^_^

~TJ

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

[Tab Atkins Jr.]

On Tue, Apr 14, 2015 at 10:53 PM, Robert O'Callahan
rob...@ocallahan.org 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. you're processing an existing image.

 For #2, you want the ImageBitmap's size to be the intrinsic size of the
 element.

 For #1, you don't care about having an intrinsic size. Instead the
 element's size is set by CSS and you want the ImageBitmap to fill the
 element, and you want to be able to use renderedPixelWidth/Height to size
 the ImageBitmap. However, for these use-cases I think the behavior
 currently specced in the OffscreenBitmap proposal doesn't make sense:
   // The ImageBitmap, when displayed, is clipped to the rectangle
   // defined by the canvas's instrinsic width and height. Pixels that
   // would be covered by the canvas's bitmap which are not covered by
   // the supplied ImageBitmap are rendered transparent black.
 I'm not sure what this means now. Suppose the canvas element has CSS
 width:100px; height:100px and the canvas rendered size is 200x200. If the
 application creates a 200x200 ImageBitmap and installs it in the canvas, as
 specced isn't this just going to display some 100x100 subrectangle of the
 ImageBitmap, cropping out the rest?

I believe this is *intending* to say that ImageBitmap is just spammed
into a canvas directly, matching pixels 1-to-1.  If the ImageBitmap
overflows the canvas in some dimension, the extra is discarded; if
it underflows, the underflow is painted transparent black.  CSS has no
effect on this.  This needs to be stated more explicitly, of course.

The idea is that this isn't drawing an image into the canvas, it's
like loading an ImageData.

 What if instead of a new context type, we had a method on the canvas
 element itself to install a new ImageBitmap, which replaces the backbuffer
 and sets the intrinsic size of the canvas element to the ImageBitmap's
 size, so that 'width' and 'height' are thereafter ignored? Then if the
 canvas has non-auto CSS 'width' and 'height', the image buffer will be
 scaled to fit the CSS size and the example above will work as expected. CSS
 object-fit will then also work, so if the ImageBitmap producer lags behind
 canvas resizing for some reason, authors can use object-fit:contain (or
 cover) to display the mis-sized images in a reasonable way. (object-fit is
 also important for the case where a Worker is presenting images through an
 OffscreenCanvas and its image production may lag behind resizing of the
 canvas element on another thread; we can pass the object-fit value through
 to the compositor to ensure the temporary results look OK.)

This works for me; it avoids the author having to coordinate between
scripts and predict the size of the image beforehand.

~TJ

Re: [whatwg] Responsive image maps

[Tab Atkins Jr.]

On Wed, Mar 25, 2015 at 10:03 AM, Andrea Rendine
master.skywalker...@gmail.com 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 feature. Unfortunately, as
 current solutions are not responsive and they can't fit to how images are
 defined in a modern scenario, with scalable size and art direction, authors
 have looked for workarounds, script-enhanced or non-native (Flash maps)
 solutions.
 POSSIBLE SOLUTIONS: 1. link boxes and CSS, 2. SVG, 3. map, where
  1. CSS has a poor range of shapes
  2. See above for SVG
  3. area coordinates are absolutely defined.
 PROPOSAL: As SVG map is not viable at all in complex picture scenarios,
 and not easily viable in simple contexts, authors could benefit from map
 versatility. So a viable solution *could* be to improve a feature in order
 to make it responsive.
 The Map element improvement consortium is not an organisation I want to
 mindlessly support (basically because it doesn't exists). And unfortunately
 I tend to be verbose when I start writing. So in my last message I tried to
 make it shorter and I chose terms incorrectly.

Note that we *should* just be able to use picture in SVG, which
helps that solution.  This is generally useful (we want responsive
images inside of SVG, too), and afaict, removes the only objection to
SVG.

~TJ

Re: [whatwg] Responsive image maps

[Tab Atkins Jr.]

On Fri, Mar 20, 2015 at 1:30 PM, Andrea Rendine
master.skywalker...@gmail.com 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 svg, the stuff inside resizes along with
the svg container just fine.

 And percentage is not limited to ingegers, of course, but
 it requires a value conversion.

That math is done to sub-pixel accuracy.  It's not anything you need
to worry about.

 And I'm not sure it works with polygons.

Polygons implicitly use the px unit (the no unit unit), so you just
need to put a viewBox on the SVG to make them resize with the svg
root.

~TJ

Re: [whatwg] Responsive image maps

[Tab Atkins Jr.]

On Fri, Mar 20, 2015 at 12:22 PM, Martin Janecke whatwg@prlbr.com 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 backwards compatible to all non-graphical clients that support at
 least HTML 3.2 such as Lynx, various bots and presumably most screen
 readers. Accessibility is already solved for image maps.

 What are the accessibility implications of using SVGs? In an image map, an
 area element used as a link must have an @alt attribute providing a link
 text. It seems that an SVG could use the desc element for that purpose,
 but it isn't mandatory. Is it understood as link text by screen readers? In
 case it isn't: do screen reader vendors plan to parse SVGs and make (links
 in) them accessible in the future? What about search engines? Do/will they
 handle hyperlinks in SVGs like a and area hyperlinks in HTML?

SVG is highly accessible.  Yes, SVG a elements are followed just
like HTML a elements, and yes, screenreaders do read out desc
elements when appropriate.

~TJ

Re: [whatwg] Responsive image maps

[Tab Atkins Jr.]

On Fri, Mar 20, 2015 at 1:00 PM, Andrea Rendine
master.skywalker...@gmail.com 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 much:

svg width=... height=...
  image src=foo ... /
  a href=target1polygon points=... //a
  a href=target2rect ... //a
  ...
/svg

The markup complexity seems to be about the same as using
img/map/area, especially if you accompany it with prose like the
example in 
https://html.spec.whatwg.org/multipage/embedded-content.html#the-map-element
shows.

 And while SVG graphics offers a wider range of instruments, such
 a complexity is not always of much use. As such it could be useless to
 vectorially define parts of the image when the purpose is just to apply a
 series of shaped links on a preexisting layer-0 image, as it could happen
 with geographical maps, non-vectorial logos/charts, pre-elaborated graphics.
 What is important, instead, is that inline SVG images cannot be resized with
 CSS. And as such they aren't responsive, exactly as image maps.

svg elements can be resized by the CSS 'width' and 'height'
properties just fine.

 The only
 case where CSS resize applies to SVG graphics is when they're used as source
 for img tag (apart from IE). And in that case hyperlinks are disabled.
 What we are left with is relative measurement, expressed in percentage for
 example, but IMHO this is not optimal. On one hand, measuring on base 100
 decreases precision,

Percentages are not base 100.  They're full decimal numbers.  You're
not limited to integer percentages.

~TJ

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

[Tab Atkins Jr.]

On Tue, Mar 10, 2015 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote:
 I wanted to get the opinion of this list on how image-orientation and the 
 img element’s naturalWidth and naturalHeight properties should interact.

 I thought there was some agreement that image-orientation ought to be
 a markup feature as it affects the semantics of the image (or perhaps
 investigate whether rotating automatically is feasible):

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508

Yup, and thanks for linking the bug.

If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties.  I don't think that's in question at
all.  But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^

~TJ

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

[Tab Atkins Jr.]

On Fri, Mar 13, 2015 at 12:21 PM, Seth Fowler s...@mozilla.com wrote:

 On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 If it happens at the markup level, it should *definitely* affect the
 naturalWidth/Height properties.  I don't think that's in question at
 all.  But nobody's moved on the markup issue, so I haven't removed the
 CSS property yet. ^_^

 Not to rehash comments that I and others have already made in bug 25508, but 
 I think specifying whether we honor EXIF orientation on a per-image basis is 
 not really very interesting.

 By far the most desirable outcome, if it’s sufficiently web-compatible, is to 
 just respect EXIF orientation by default.

Yup, agreed, that's the best solution.  Let's make it happen. ^_^

 If we can’t do that, then I think content authors will mostly just opt in via 
 a single “img { image-orientation: from-image }” in their CSS. That’s the 
 simplest opt in solution that’s feasible. It’s also trivial to encapsulate in 
 a standard CSS library.

 I’m opposed to the removal of the CSS property for a markup-based solution, 
 as that will force content authors to specify “autorotate” on every single 
 img element on the page. That’s a waste of effort and bandwidth (though 
 admittedly compression will make the impact there minimal), and it makes it 
 more likely that content authors will simply forget to do so on some 
 elements. Encapsulating this solution is also significantly more heavyweight.

 Having a DOM-based way to request that EXIF orientation be respected is 
 desirable, though, so that it can be used with non-HTML uses of images like 
 canvas.

Agree with all of this.  It's still unclear, though, whether the
effects of the CSS property should be reflected in the
naturalWidth/Height properties, which is the subject of this thread.
If we can get away with just always autorotating, the question is
moot, which is ideal.

~TJ

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

[Tab Atkins Jr.]

On Mon, Mar 9, 2015 at 4:01 PM, Seth Fowler s...@mozilla.com wrote:
 Hi all!

 I wanted to get the opinion of this list on how image-orientation and the 
 img element’s naturalWidth and naturalHeight properties should interact. 
 The css-images level 3 spec says:

 The intrinsic height and width are derived from the rotated rather than the 
 original image dimensions.”

 The HTML spec says:

 The IDL attributes naturalWidth and naturalHeight must return the intrinsic 
 width and height of the image, in CSS pixels, if the image is available, or 
 else 0.”

 On the surface, it seems clear that image-orientation must affect 
 naturalWidth/Height. However, I’m not sure whether this was intended, and I 
 don’t have a strong intuition for whether this is more or less surprising to 
 content authors than having these two features be totally independent.

 There is certainly a potential performance cost if the two features do 
 interact, since that means that naturalWidth/Height will depend on style 
 information. On the other hand, naturalWidth and naturalHeight would 
 definitely take EXIF orientation into account if we respected it by default, 
 so perhaps they also should when content authors opt in to EXIF orientation 
 support using image-orientation.

 Let me know what you think.

That's a good question.  I suspect that .naturalWidth/Height should
return the image's dimensions before applying CSS rotations.  This is
likely to be surprising, but also probably the correct answer for
separation-of-concerns reasons.

I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm.

~TJ

Re: [whatwg] scrap the srcset attribute

[Tab Atkins Jr.]

On Mon, Mar 2, 2015 at 1:08 PM, Michael A. Peters
mpet...@domblogger.net 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');

 Then I can check it - if it is relative, I can change it to reference the
 cdn. If it is not local, I can check to make the domain is valid, check the
 domain is not in our black list, etc. and then replace the src node with the
 cleaned version.

 With srcset - I can still do that but then becomes more complex as there is
 an initial array that then has to be exploded into secondary arrays etc. and
 more complicated code is more prone to bugs.

When designing the syntax, we optimized for authoring and updating by
hand, not for JS-based manipulation.  That's a far lesser use-case.
You shouldn't be sending pages with img src that you intend to
change in ways that could be done server-side (all of the things you
mention qualify), as it defeats the preloader and causes users to send
multiple requests, degrading the user-experience significantly for no
real benefit.

 What happens if one of the sources has a typo involving a space, e.g.

 Big Image.jpg 2x

 instead of

 Big%20Image 2x

 With key=value that's easy to fix, but it is more complicated when a space
 is a delimiter in an array that is a sub-array.

 key=value is kiss and kiss has a lot of benefits.

Then you have an authoring error.  The HTML validator will catch that.
Spaces in filenames are rare, luckily, as are commas, which is part of
why the syntax uses those.

We did consider simpler solutions like you're suggesting; they end
up sufficiently verbose and frustrating to write out that it's worth
the added complexity that we settled on.

~TJ

Re: [whatwg] scrap the srcset attribute

[Tab Atkins Jr.]

On Mon, Mar 2, 2015 at 8:46 AM, Michael A. Peters
mpet...@domblogger.net 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, sometimes it has
 codecs specified there too - but that's the only example I can think of, and
 even there, it is rarely actually used. Usually it is just simply used as a
 key=value pair with the mime type, even by me and I know how to specify the
 codec.

 But srcset is a multi-level array. The first array is a , delimited string -
 and each element between the commas is itself a space delimited array.

 When has that kind of attribute ever been previously used in HTML ??
 I suppose the type attribute with audio and video where you can optionally
 specify codec, but that's all I can think of, and there it isn't
 multi-dimensional.

 srcset is a mistake. A mistake that will result in errors on the web because
 it is much more difficult to understand than the traditional key=value pair
 that is traditional in HTML and XML.

 key='multi level array of values' is just plain conceptually wrong.

srcset may be on the high end of complexity for HTML, but it's square
in the middle for CSS.  CSS doesn't seem to confuse and confound
people (at least, its syntax generally doesn't).

 -=-

 Secondly, you are doing the source child of the picture element wrong.

 Who the hell am I to tell you that you are doing it wrong?

 I'm a user that thinks what you currently have is over-complicated and
 ridiculous.

 When in the history of HTML has an element's legal attributes been dependant
 upon what the parent element is?

 I can't think of a case until the picture element.

meta, for instance.  But just because something is the first doesn't
mean it's a bad thing.  (We didn't particularly like it when
designing, either, but it was better than breaking precedent and
having picture use a *different* child element than audio and
video.)

 The picture element should have the source element as a child, and this is
 how it should be done:

 [picture]
   [source src=ImageHD.webp type=image/webp media=(min-width: 1024px)
 /]
   [source src=ImageHD.jpg  type=image/jpeg media=(min-width: 1024px)
 /]
   [source src=ImageHD.webp type=image/webp media=(min-width: 800px)
 res=2x /]
   [source src=ImageHD.jpg  type=image/jpeg media=(min-width: 800px)
 res=2x /]
   [source src=Image.webp   type=image/webp media=(min-width: 800px) /]
   [source src=Image.jpg type=image/jpg  media=(min-width: 800px) /]
   [source src=Image.webp   type=image/webp res=2x /]
   [source src=Image.jpgtype=image/jpg  res=2x /]
   [source src=ImageMobile.webp type=image/webp /]
   [source src=ImageMobile.jpg  type=image/jpg  /]
   [img src=Image.jpg alt=[cow patty in field] /]
 [/picture]

 The client selects the first image where it matches all type, media query,
 and resolution attributes that are specified.

 Notice that it keeps the simple to understand key=value pair for the
 attributes, and it keeps compatability with source tag as it has already
 been used with audio and video for years now.

As it turns out, this kind of syntax is extremely verbose for common
cases, and doesn't even work all that well when you get down to it.

Your example can be boiled down to the following:

picture
  source type=image/webp sizes=50% srcset=ImageMobile.webp 400w,
Image.webp 800w, ImageHD.webp 1600w
  source sizes=50% srcset=ImageMobile.jpg 400w, Image.jpg 800w,
ImageHD.jpg 1600w
  img src=image.jpg alt=cow patty in field
/picture

(I'm making some assumptions about your image size and how it'll be
displayed.  Obviously you can tweak that.)

This is much easier to write and to maintain, and responds better - it
lets the client make the decision of which version it wants based on
more than just screen size, and it handles 3x and higher screens
automatically.

~TJ

Re: [whatwg] resize events on elements

[Tab Atkins Jr.]

On Mon, Feb 23, 2015 at 8:16 PM, Ryosuke Niwa rn...@apple.com wrote:
 On Feb 23, 2015, at 5:40 PM, Dean Jackson d...@apple.com 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 scenarios where this is extremely 
 useful, and is otherwise difficult or annoying (e.g. checking your size on a 
 timer).

 The idea was to allow the resize event on elements. I don't really care what 
 the solution is, so maybe someone here can come up with a better idea (size 
 observers?). And of course there are a lot of details to be worked out.

 I would like it be an async event on an element although we might want it to 
 fire earlier than setTimeout(~, 0) to avoid FOC (maybe the same timing as 
 rAF?).  I don't think end-of-microtask makes sense as that may force too many 
 layouts.

Yeah, you almost certainly want to tie it to rAF timing.

~TJ

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

[Tab Atkins Jr.]

On Sun, Nov 16, 2014 at 4:38 PM, Biju bijumaill...@gmail.com 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/about/contribute/photosphere/
 Surround shot http://www.samsung.com/us/support/faq/FAQ00057110/74008

These are just alternate image formats, yes?  In that case, browsers
can expand their img support to allow pointing to these kinds of
files.  They'd need some sort of native controls on the img element,
I suppose.

~TJ

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

[Tab Atkins Jr.]

On Wed, Nov 5, 2014 at 5:07 PM, Bruno Racineux br...@hexanet.net 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 latter is not true as currently implemented.
 The former allows a css enabled styled presentation to display a hidden
 element,
 while browsing with *styles disabled* with have the element hidden (not
 displayed)
 due to the default browser stylesheet making it so.

 Technically it is therefore *not* hidden form all presentations and
 breaks the hidden = aria-hidden accessibility assumptions. I find this
 conflicting.

 And allowing a css override, breaks my use case:

 Say, I have a link: a class=email hiddenEmail/a . And I only want this
 link to
 render dynamically and conditionally as a mailto: href with a
 'display:block' style.
 I am unable to pre-style my links with a 'display:block', because it cancels
 'hidden',
 which makes 'hidden' useless to me here if it wasn't for a *[hidden] {
 display: none; }
 at the end of my stylesheet.

 I strongly suggest that hidden be made a 'display: none !important' instead
 to remedy this confusion.

 [1] https://html.spec.whatwg.org/#the-hidden-attribute

This is intentionally *not* done, so that authors can hide it using
whichever technique they wish; in particular, authors need to be able
to do a transition of styles when setting/removing 'hidden', like
fading it to/from opacity:0.  Forcing it to display:none would prevent
these kinds of animations.

~TJ

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

[Tab Atkins Jr.]

On Sat, Nov 1, 2014 at 7:18 AM, Stefan Reich
stefan.reich.maker.of@googlemail.com 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 sample HTML source
 plus IMAGES of how they look rendered.

 That, my AI could work with.

 Also, I think this is very important to have - I vividly remember all those
 years of fighting with browser inconsistencies and the very undefinedness I
 am talking about that still exists. (More on my blog at tinybrain.de).

 Q: Does such a test suite for HTML exist? If not, it is time to create that.

 Alternatively, what one could create is a virtualized browser. My AI could
 also learn from that, basically. But a virtualized browser is a complicated
 piece of software, and there is no proper infrastructure for virtual
 programs yet (another lack in IT today).

 So I assume a test suite of sources + images will be easier to make right
 now.

 Let's define HTML properly!

The behavior of HTML is well-defined; where it's not, it's a bug, and
reporting it would be appreciated.

You're talking about rendering, which is the domain of CSS.  CSS
should also be reasonably well-defined.

Examples, including example renderings, are often useful for
understanding, but they're never part of an actual definition. They
just help the reader visualize something quickly, rather than
requiring them to understand it all from the code.

~TJ

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

[Tab Atkins Jr.]

On Oct 7, 2014 11:32 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
  On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl
wrote:
  On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
  dome...@domenicdenicola.com 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), or whether we want developers to ask the API
whether they were granted permission (in which case it should give back a
boolean fulfillment value or similar).
 
  How can they assume permission is always granted? It's up the user.
  It's a request from the developer and the user can say no. What's
  unclear about the name?
 
  Yeah, you misunderstood the question.  It's about whether permission
  failure should reject the promise or accept it with a boolean.

 Domenic did not ask a question. I asked a question since it's unclear
 to me why a developer could reasonably assume they will always get
 permission.

You're missing context or something.

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
like using Promise.all() to join multiple permission requests together and
get a nice combined promise that fulfills when everything succeeds, or
write a nice straight success path that assumes permission, and then handle
any errors, including denied permission, at the end, rather than
interleaving error-handling logic into the middle of your code.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 8, 2014 at 1:07 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com 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
 like using Promise.all() to join multiple permission requests together and
 get a nice combined promise that fulfills when everything succeeds, or write
 a nice straight success path that assumes permission, and then handle any
 errors, including denied permission, at the end, rather than interleaving
 error-handling logic into the middle of your code.

 Okay, given that question I agree it's natural to assume that this
 happens when it resolves. However, a user declining permission is not
 exceptional behavior and therefore should not cause an exception. In
 synchronous code you would not want to write try/catch here.

An error or failure event *is* an asynchronous exception.  It's a
completely different code path from the success event that you can
handle separately, while writing code for the success path that
assumes you got the things you needed.

Do you think that every single instance of error events we've used in
the past was a mistake, and we should have instead just had a
complete event that both success and failure used?  For example,
should img.onload fire when the image fails to load?  This is
*exactly* analogous to a permission request succeeding or failing, as
far as I can tell, but for the equivalent image situation, I believe
you're okay with a failed load rejecting the .ready promise (or
whatever we're planning to name it).

There are certainly cases where only actual exceptions would cause
rejection - Domenic's example of a userAllowsNotifications()
function is clearly going to fulfill with a boolean, and only reject
if you fuck something up.  But requesting a permission is an operation
that can fail, and failure is exceptional, and we've reflected this
precise distinction in tons of past APIs via an error event.  Why was
every single past API that used this pattern mistaken?

Again, if this means that the current design for await becomes less
convenient, *we can fix await to work better*. It's not set in stone,
it's not developed yet.  This is a thing we can change.  But let's not
twist our necks around and force promise APIs into an unnatural and
inconvenient shape just because a naive translation to sync code
produces errors and people find try/catch annoying or distasteful.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 8, 2014 at 1:31 AM, Tobie Langel tobie.lan...@gmail.com wrote:
 On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. jackalm...@gmail.com 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
 like using Promise.all() to join multiple permission requests together and
 get a nice combined promise that fulfills when everything succeeds,


 This is as simple as:

 Promise.all(permissionRequests).then(function(results) {
 if (results.every(x = x === granted)) // …
 });

 But I don't think it's the right approach to handling permissions in
 general. Developers should handle granted permissions as progressive
 enhancements, not balk when they don't get all the permissions they
 required. Using exceptions for denied permissions sends a completely wrong
 message imho, especially when it's combined with Promise.all.

I don't think moral arguments really have a place here.  Whatever
mitigation code that authors write to handle failed permissions can go
in the reject handler exactly as easily as in the fulfill handler.
That we believe authors should handle permission failures
intelligently doesn't, itself, mean that we should make the success
path less convenient.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
 dome...@domenicdenicola.com 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 is all. So yes, agreed with Tobie et al.

You keep arguing from the future rejections become errors position.
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
nobody seems to complain argument.

Do you dislike img.onerror firing when the image doesn't load?  (And
same for all the other resource-loading elements.)  Do you dislike
geolocator.getCurrentPosition calling the failure callback when the
user refuses permission?  Do you dislike IDB firing error events on
several types of failure, ranging from exceptional to mundane?

If there are any of these you do *not* dislike, why?  And why doesn't
the logic from those apply to this situation?

On Wed, Oct 8, 2014 at 9:18 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
 Ah, this is the crux of our minor-disagreement, I think.

 IMO using try/catch for a common failure case is fine, *as long as you want 
 that failure to bubble up the call stack*. E.g., if you want to handle it at 
 a higher level along with other failures, or if you want to ignore the 
 possibility of failure except in how errors get sent to `window.onerror`.

 Now, I think we're likely in *agreement* that you don't actually want to do 
 this for requestPermission---you should handle it as soon as possible. But 
 our reasoning is different, and now I understand why.

The problem here is that try/catch *is* distasteful, while promise
rejection isn't, and it's all ergonomics.

* try/catch produces rightward drift, promise reject handlers do not
* errors bubble up indefinitely until they're caught, breaking all of
your code.  Rejections bubble down a single promise chain, and can be
ignored if you're done with a chain without anything bad happening.
(And some Promise algebra functions like .race() can swallow a
rejection without rejecting the chain, if another one fulfilled first,
so you don't even have to think about the rejection.)
* We've been taught not to use exceptions for control flow, but we
have the Promise algebra to help us do control flow based on promises
fulfilling/rejecting (and more mature Promise libraries tend to grow
more algebra over time).

Errors suck, but they're the way we do rejections syncly.  I hate that
we're compromising on the built-in ergonomics of Promises in order to
avoid triggering the worse ergonomics of errors in the future. :(

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. jackalm...@gmail.com 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
 nobody seems to complain argument.

 A user saying no to notifications is not an error. You ask the user to
 make a decision, the user decides. Either way is a success. An error
 would be invoking the method in the wrong way.

This is 100% arguable, and based solely on the *precise* manner in
which you are assigning semantics to the name.

If we named the method getNotifier(), and it requested permission as
a side-effect, would you call failure to get the notifier due to
refusing permission an exceptional situation?

 Do you dislike img.onerror firing when the image doesn't load?  (And
 same for all the other resource-loading elements.)

 That makes sense. Network errors are rather exceptional. Note that it
 does not error for a 404 (unless it can't decode the response, which
 again, is rather exceptional).


 Do you dislike
 geolocator.getCurrentPosition calling the failure callback when the
 user refuses permission?

 I would expect that to be done differently today, yes.

Why?  getCurrentPosition is asking for the current permission.  If you
fail to get the current position, why would you call that a success?
What would you even pass to the success callback?  A neutered position
object?  A position object with default values, plus an extra field
saying lol no this isn't real?

~TJ

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

[Tab Atkins Jr.]

On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
 dome...@domenicdenicola.com 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), or whether we want developers to ask the API whether 
 they were granted permission (in which case it should give back a boolean 
 fulfillment value or similar).

 How can they assume permission is always granted? It's up the user.
 It's a request from the developer and the user can say no. What's
 unclear about the name?

Yeah, you misunderstood the question.  It's about whether permission
failure should reject the promise or accept it with a boolean.

~TJ

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

[Tab Atkins Jr.]

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

 Might be worth considering, it's relatively cheap to support and can be
 implemented without breaking backwards compatibility.

 One minor risk with also returning a promise is that exceptions for
 incorrect invocation would no longer throw an exception, but instead
 reject the promise.

 Otherwise I would never expect this promise to be rejected as the user
 declining notifications is not exceptional.

Wait, what?  Anytime you request something, not getting it is
exceptional.  Not sure how you can make an argument otherwise.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. jackalm...@gmail.com 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 synchronous version of this method (were it to
 exist) to have to use try/catch for anything other than invoking it
 with an argument such as TEST, which is clearly wrong. That's why I
 don't think it's exceptional (e.g. warrants an exception/rejection).

And I wouldn't expect someone loading a FontFace synchronously to use
try/catch to deal with loading errors, either, because that's super
obnoxious.  Failure, though, is a standard rejection reason - it maps
to the use of onerror events.

Without it, the promise algebra functions become far less useful, and
you have to type-test the fulfillment value to see if it's actually
the value you want, or some sort of proxy that communicates failure.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 1, 2014 at 9:34 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. jackalm...@gmail.com 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
 obnoxious.  Failure, though, is a standard rejection reason - it maps
 to the use of onerror events.

 Without it, the promise algebra functions become far less useful, and
 you have to type-test the fulfillment value to see if it's actually
 the value you want, or some sort of proxy that communicates failure.

 Once we have async/await syntax the synchronous version is what you
 get. I would not want try/catch for requestPermission() there. As far
 as I know promises are just like functions in that regard, you only
 want to reject/throw if you want to force try/catch on the user.

Yeah, this is a mismatch of expectations based on how you use it.

If you're using Promises, and the promise algebra like .all() or
.race(), you expect only success to result in fulfillment; failure
should reject, so you can specialize your code paths properly and have
the algebra work well.  I want to be able to use Promise.all() on
several permission requests to tell if I get them all; if they always
fulfill, Promise.all() becomes solely a synchronization primitive, not
a useful value algebra operation.

If you're using async/await to hide the asynchrony, you only want
error situations to throw, because dealing with throwing is really
annoying.

This is actually kinda terrible.  Promises make it *really easy* to
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..  Promise is basically an
async Maybe monad, which is great, because Maybe is useful for
*exactly the scenario I just outlined*.

Changing things so that you have to go back to wrapping all your code
in try/catch (and not just the one call - if you're chaining promises,
they *all* have to be wrapped) is kinda terrible, and distorts the
ergonomics of the system.  What was once great, when done directly
with Promises, is now terrible, when done with async/await; you're
forced to pay for that convenience!

I think we should develop Promises in a way that exploits their
ergonomics properly, and then rethink async/await a bit to make it
match those ergonomics, rather than fighting them.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 1, 2014 at 11:44 AM, Domenic Denicola
dome...@domenicdenicola.com 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 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..  Promise is basically an async Maybe monad, which is 
 great, because Maybe is useful for *exactly the scenario I just outlined*.

 This is exactly the wrong way to think about promises. Promises are the 
 async return/throw monad; if you want a Maybe, then you have to compose 
 that in yourself. People often try to abuse the fact that they have a second 
 branch for exceptions in order to use it as a generic container for go down 
 two possible flow paths, but that is very incorrect. An earlier comment in 
 the thread about we have three possible mechanisms is also symptomatic of 
 this incorrect thinking. We have two mechanisms: return and throw. When you 
 wrap those in async, they become fulfill and reject.

 I think we should develop Promises in a way that exploits their ergonomics 
 properly, and then rethink async/await a bit to make it match those 
 ergonomics, rather than fighting them.

 We are not changing the model of promises in this way. If you want a Maybe 
 monad, that's a separate API that you'd want to spec.

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
contrary to the way that existing non-promise async APIs are
constructed, and I expect quite contrary to most people's
expectations.

Geo, for example, throws if you pass bad arguments, but then routes
its result through either a success or error callback.  This is
*directly* analogous to the signature of Promise.then(), and I think a
lot of people would expect a getCurrentPosition() that returned a
promise would have the same behavior.  This allows you to just assume
that the value passed to the success callback is a position, and write
code accordingly.

It feels like your position leads directly to the error handling in
two places problem that you, I, and others railed against in the
promise-returning functions should never throw debate.  You have to
handle bad arguments in the reject callback to the promise, and handle
failure in the fulfill callback.  It'll lead to a ton of boilerplate
`if(arg == null) throw;` at the top of fulfill callbacks, so that the
fulfill chain is *actually for the successful case*.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 1, 2014 at 11:52 AM, Jeffrey Yasskin jyass...@chromium.org wrote:
 On Wed, Oct 1, 2014 at 6:06 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo bever...@google.com wrote:
 One argument I came across for overloading requestPermission is the
 following:
 Promise.all([ Notification.requestPermission(),
 swRegistration.push.requestPermission() ]).then(...);

 Might be worth considering, it's relatively cheap to support and can be
 implemented without breaking backwards compatibility.

 One minor risk with also returning a promise is that exceptions for
 incorrect invocation would no longer throw an exception, but instead
 reject the promise.

 Otherwise I would never expect this promise to be rejected as the user
 declining notifications is not exceptional.

 On a distributed system, a network error isn't unusual either, but it
 still makes sense to treat it as an exception because the
 application's main codepath can't continue executing. Similarly, if a
 permission the application expects isn't granted, the application has
 to skip the rest of its main codepath, so it makes sense to treat that
 as an exception too.

Precisely.

 If Tab wants to avoid try/catch blocks around most of his code, he can
 simply avoid using await for those promises, and transform their
 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're right.  try/catch is just more annoying to use than a
.catch() at the end of a promise chain. ^_^

On Wed, Oct 1, 2014 at 11:34 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 I think we should develop Promises in a way that exploits their
 ergonomics properly, and then rethink async/await a bit to make it
 match those ergonomics, rather than fighting them.

For example, we could have *two* keywords for awaiting - one that
throws all rejections, and one that converts non-fatal errors
(tagged in the exception somehow) into fulfills for you automatically.
Or a method on Promise.prototype that does the same.  That way a
permission rejection can reject a promise usefully (letting you count
on the success path as meaning I got permission), and someone can
still, if they wish, handle no-permission in their normal code path
and leave errors for actual coding errors.

~TJ

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

[Tab Atkins Jr.]

On Wed, Oct 1, 2014 at 1:02 PM, Tobie Langel tobie.lan...@gmail.com wrote:
 On Wed, Oct 1, 2014 at 5:59 PM, Tab Atkins Jr. jackalm...@gmail.com 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
 contrary to the way that existing non-promise async APIs are
 constructed, and I expect quite contrary to most people's
 expectations.

 I'm with Domenic, here. We had these conversations for the Service Worker
 Cache's .match() method and dropped promise rejection in favor of resolving
 with null when a relevant Response object couldn't be found in the cache.
 Rejecting the promise was left for truly exceptional cases, such a data
 corruption issues.

 I agree with you that the code branching provided by the resolve/reject pair
 looks appealing at first, but it's terrible once awaits comes in the
 picture.

Wow, that's kinda terrible.  The operation literally failed; there is
no way in which it could be said to have succeeded, and you absolutely
want to run different code paths based on whether it succeeded or
failed.  Instead, you are forced to either run your failure-path code
in the fulfill callback alongside the success-path code, or do what I
said upthread and add a `if(arg == null) throw` line to the top of
your fulfill callback so you can treat the fulfill callbacks as always
succeeding.

Note that Python, for example, throws errors on dict keys not being
found (unless you specifically tell it a sentinel value to return
instead).  Do you think that's terrible?

This sort of behavior makes promise rejection essentially worthless.
You can't base anything off of whether a promise fulfilled or not,
because it'll only fail for weird exceptional cases; most of your
failures (cases where the thing you were asking for couldn't be
done) are instead mixed into your fulfill channel.

~TJ

Re: [whatwg] ARIA semantics of implied rows

[Tab Atkins Jr.]

On Fri, Sep 26, 2014 at 11:39 AM, Daniel Trebbien dtrebb...@gmail.com wrote:
 On Fri, Sep 26, 2014 at 2:09 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien dtrebb...@gmail.com
 wrote:
  One issue is that the ARIA semantics for implied rows are not defined.

 I'm not sure I understand why ARIA would come into play at all when it
 comes to tables. Weren't tables accessible (I realize it has always
 been somewhat hard to convey them properly) long before ARIA existed?


 The issue is that, as far as I can tell, HTML 4.01 does not support
 implied rows:
 http://www.w3.org/TR/html401/struct/tables.html
 This is new to HTML5.

No, HTML4 supported this; it probably didn't actually have any
normative text around it, but browsers certainly supported having a
rowspan go past the end of the explicit rows.

~TJ

Re: [whatwg] Notifications and service workers

[Tab Atkins Jr.]

On Thu, Sep 25, 2014 at 4:24 PM, Jonas Sicking jo...@sicking.cc 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 respond, dismisses
 notification
 * Close event
 * Message sent to the server to make message as read
 * Notifications auto-dismissed on other devices the user has

 Hmm.. is close really a decent proxy for read? I personally often
 read notifications without clearing them, since I read the temporary
 on-screen notification. And on occasion when my notification tray
 overflow, I clear notifications without reading them.

 But I hate using my own usage patterns in design. Do we have any data
 on what native applications do with similar callbacks? Assuming they
 exist in other notification platforms...

The use-case presented by Jake seems precisely opposite what actually
happens today in multiple apps, as I alluded to in my previous email:

 * Alternatively, maybe we could simply get rid of the close event
 entirely. Does it have a use-case?

 I'm also not sure, on first thought, how an app would respond to a
 close event.  I don't think that apps on Android currently care if you
 close a notification?  At least, nothing that I use seems to do
 anything about it; IRCCloud, for example, doesn't mark mentions as
 already read if I close the mention notification.  Some use-cases
 would be useful.

None of Twitter, Hangouts, or IRCCloud cares a whit if you close their
notifications; they still record stuff as unread until you actually
visit the app.  I can't recall any other app I've ever used treating a
notification closing as a significant event and taking any action,
either.  So, at least based on my immediate testing and long-term
memory of the notification patterns of the apps I use, I don't think
there's any use-case for a close event.

The one example I can think of that's kinda like this is the Google
Maps Navigation Notification.  It actively resists being closed, for
one thing, but it does have a Dismiss button on itself (because it's a
Rich Notification or whatever), which when pressed also cancels
navigation in the app.  This seems like a specialized function of the
app itself, using some future form of rich notifications, though, and
not something we can or should generalize to other apps.  It's
definitely not an example we should generalize to generic clearing
out all my notifications behaviors, because it explicitly resists
such things and requires an affirmative and purposeful action on the
part of the user to dismiss it.

~TJ

Re: [whatwg] Notifications and service workers

[Tab Atkins Jr.]

On Tue, Sep 23, 2014 at 5:21 PM, Jonas Sicking jo...@sicking.cc 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 goes away.
 * Notifications that close when a page goes away does not seem useful
 on mobile, but could be useful on desktop to enable minimized
 applications, or applications whose window is covered by other
 windows, call attention to themselves.

Can you provide an example use-case for a persistent notification that
goes away when the page does?  I can think of transient notifications,
and persistent ones that stick around until dismissal, but I can't
come up with this in-between case with a few minutes thought.

 * Persistent vs. non-persistent doesn't seem like a platform
 difference, but rather two different types of notifications that
 content could want to create.

Yes.  Pandora temporarily spawning a notification showing the song
title/artist that's playing whenever a new song starts seems useful as
a non-persistent notification on any platform.  I definitely wouldn't
want that sort of thing to stack up on a mobile device.

 * For persistent notifications, in cases where the application cares
 about the user clicking on the notification (as opposed to
 fire-and-forget notifications), we should always send a notification
 to the service worker. In this scenario it never seems useful to fire
 an event on the Notification instance since that will just mean
 multiple codepaths trying to handle the same click. At best that would
 be wasted performance, at worst it could mean broken UI or application
 logic.
 * Same applies to close in addition to click.
 * For non-persistent notifications, it seems good to not require that
 a service worker is used.

I'm not sure persistent vs non-persistent is quite the line to draw
this on.  Fire-and-forget vs responsive seems more correct.  Most
(all?) persistent notifications are responsive, yes, but transient
notifications might or might not be.  I think it's appropriate and
useful for a fire-and-forget notification to be fireable from a normal
page, without a service worker.

 * I'm uncertain about if non-persistent notifications are important
 enough to target at this point. But I'm heavily biased from having
 worked mainly on mobile web lately.
 * Right now the spec requires that whenever a user interacts with a
 persistent notification, the application that created the notification
 is immediately started so that we can send the appropriate
 click/close/future-button-press event to it's service worker. This can
 be quite expensive. At the very least applications need to be able to
 indicate that they don't need to be told about the close event.
 * Even better would likely be content could indicate which events they
 want fired at the service worker when creating a Notification. Other
 events would be dropped. This list vary by-notification, not by-app.

Yes, seems useful.

 * Alternatively, maybe we could simply get rid of the close event
 entirely. Does it have a use-case?

I'm also not sure, on first thought, how an app would respond to a
close event.  I don't think that apps on Android currently care if you
close a notification?  At least, nothing that I use seems to do
anything about it; IRCCloud, for example, doesn't mark mentions as
already read if I close the mention notification.  Some use-cases
would be useful.

~TJ

Re: [whatwg] CanvasRenderingContext2D and CSS Image filters

[Tab Atkins Jr.]

On Thu, Sep 18, 2014 at 11:15 AM, Vivek Galatage viv...@chromium.org 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 drawImage.
 Here is the link, http://imgur.com/7OgXEwp, to the screenshot of the
 behavior on chrome and FF.

 The question is: Should the filter even be applied to the bitmap drawn on
 the canvas?

CSS filters are a rendering-time operation.  They don't do anything to
the image data itself, which is what canvas uses when you call
drawImage().

~TJ

Re: [whatwg] Canonical Image and Color

[Tab Atkins Jr.]

On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren ann...@annevk.nl wrote:
 On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru 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 by Apple and Android
 - msapplication-TileImage used by MS
 - Firefox OS icon (detached case)
 - SpeedDial API by Opera (as an extension)

 There's also link rel=icon, which is the way to do this.

Particularly when used with the sizes='' attribute, which lets you
provide small favicons *and* large icons suitable for use in tiles
like this.

~TJ

Re: [whatwg] Canonical Image and Color

[Tab Atkins Jr.]

On Tue, Aug 26, 2014 at 4:59 AM, Mike tomshin...@yandex-team.ru 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 
 screenshots with nice logos like this:
 https://dl.dropboxusercontent.com/u/1830800/ss_tablo.jpg

 This page icon might also contain a notification counter that would enable 
 website to communicate with user and improve retention. Similar to mobile 
 icons and notifications. But on desktop there might be more than one counter.

 * Counter use-cases:
 1.Mail (gmail, yahoo, yandex) - number of unread/new emails.
 2.Social Networks (Facebook, Twitter, LinkedIn etc) - number of 
 notifications, messages, friends requests.
 3.E-commerce (Amazon, eBay, TaoBao etc) - number of cart items (waiting list 
 items)
 4.Microblogs and contend-based platforms (tumblr, youtube, ask, quora, news 
 website etc) - number of new content.

 * How the standard could look like:
 link rel=“newtabpage_icon href=“logo_url show_title=“true/false” (optional 
 attribute; default: false - for main page; true - for internal) 
 ntp_manifest=“manifest_url” (optional attribute; only for counter 
 implementation) /

 * How the manifest could look like:
 I would suggest to postpone this discussion for later and focus on the first 
 part. Step by step.

 * What kind of issues do I see:
 1) There’re 3 general formats of page icons:
 a) square in Chrome, Opera
 b) floating in FF and Safari
 c) fixed ratio in Yandex (1:2), Maxthon (1:1,4)
 Obvious there should just one icon provided by webmaster. So we need to agree 
 on the aspect ratio (and size). Thus some developers will need to find a way 
 how to handle it. But I believe it’s just a matter of fitting and resizing.
 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 by Apple and Android
 - msapplication-TileImage used by MS
 - Firefox OS icon (detached case)
 - SpeedDial API by Opera (as an extension)

 In Yandex.Browser we think how to improve our Tablo API and we would prefer 
 to use some common approach rather than developing a proprietary standard. So 
 guys, what do you think? Is there a place for such kind of standard or it’s 
 already too tight among those semi-standards?

The 'theme-color' meta value recently proposed and standardized by
Android covers the color use-case, at least.

~TJ

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

[Tab Atkins Jr.]

On Wed, Aug 20, 2014 at 12:39 PM, Mark Callow
callow.m...@artspark.co.jp 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 something like 1% of pages in Alexa's top 
 78K pages
 1%! Significant? Hardly. Typo?

The web corpus is somewhere north of a trillion pages.  1% of that is
still 10 billion+.

Even for things that aren't evenly distributed, and so occur mostly on
newer content, 1% is a large fraction, which people are likely to run
into on a roughly daily basis.

Chrome, for example, only starts considering whether a feature can be
removed when its usage is under .01% (we usually prefer it to be less
than .003% or so).

~TJ

Re: [whatwg] Proposal: Wake Lock API

[Tab Atkins Jr.]

On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr 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 indefinitely (until the
 user leaves the page of course).

 I.e. an unbalanced request() and release() in both the currently
 proposed API, and in the API that I propose behave the same, the lock
 is held indefinitely. Any objects getting GCed does not change this.

 I overlooked that aspect, my apologies. It sounds good. I am not sure if
 that would be safer than global methods in the sense that developers
 will still be able to shoot themselves in the foot by not calling
 .release() or might assume that .release() will be called upon object
 destruction.

 How would you handle feature detection with this design?

Assuming there are multiple types of wakelock classes, you just test
for their existence.

~TJ

Re: [whatwg] Proposal: Wake Lock API

[Tab Atkins Jr.]

On Tue, Aug 19, 2014 at 11:07 AM, Jonas Sicking jo...@sicking.cc wrote:
 On Tue, Aug 19, 2014 at 5:35 AM, Mounir Lamouri mou...@lamouri.fr 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() classes.

Which, as others have noted, are what we want to do anyway, beyond the
feature-testing angle.  Different WakeLocks can grow different methods
down the line.

~TJ

Re: [whatwg] Proposal: Wake Lock API

[Tab Atkins Jr.]

On Tue, Aug 19, 2014 at 1:29 PM, Marcos Caceres w...@marcosc.com 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() and SystemWakeLock() classes.


 Might make sense to do it this way regardless. It might be that we need to 
 add different behavior for each type of lock in the future.

 Ok, so taking into consideration the feedback received so far - how about 
 something like:

 ```
 [Constructor]
 interface DisplayLock : WakeLock {
static readonly attribute boolean isHeld;
 }

 [Constructor]
 interface SystemLock : WakeLock {
static readonly attribute boolean isHeld;
 }

Why is isHeld still used here?  You don't need it to avoid squashing
someone else's lock with this design, and several people have pointed
out that exposing it is a footgun, as people might check it and decide
they don't need to request their own lock (only to be screwed when the
other lock releases earlier or later than they expected).

~TJ

Re: [whatwg] Proposal: Wake Lock API

[Tab Atkins Jr.]

On Tue, Aug 19, 2014 at 1:44 PM, Marcos Caceres w...@marcosc.com 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 people have
 pointed out that exposing it is a footgun, as people might check it and
 decide they don't need to request their own lock (only to be screwed when
 the other lock releases earlier or later than they expected).

 It's the only authoritative source of truth. But ok, fair point about the 
 footgun.

 Consider the static dropped.

I mean, you could put a non-static isHeld on any individual lock, if
you want to know whether this particular lock is held or released.  I
just don't think there's any reason to pass information around about
the global lock state, if you're not being required to use that
information for coordination purposes.

~TJ

Re: [whatwg] Proposal: Wake Lock API

[Tab Atkins Jr.]

On Sat, Aug 16, 2014 at 9:19 AM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
 Jonas Sicking jo...@sicking.cc writes:
 On Fri, Aug 15, 2014 at 6:14 AM, Mounir Lamouri mou...@lamouri.fr 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 means that pages that contain multiple independent
 subsystems will have to make sure that they don't stomp on each
 other's locks. Simply counting request() calls vs. release() calls
 helps, but doesn't fully solve the problem. It's very easy to
 accidentally call release too many times, in response to some UI
 action for example.

 An alternative design would be something like

 x = new WakeLock(display);
 x.request();
 x.release();

 Extra calls of either request() or release() are ignored, but pages
 can create any number of WakeLocks of the same type.

 It seems that we already discussed using an object and this solution was
 dismissed because of this model being error-prone.

 Where was this discussed? Why was it considered more error prone? Was
 it related to the patterns discussed at

 http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2014-August/297431.html

 It's also not clear
 how this solution is superior than the current solution [1] with regards
 to multiple releases or requests. In [1], if you call .request() or
 .release() multiple time, the promise reacts appropriately.

 The problem arises when you have several semi-independent pieces of
 code within a single page. Given that request() and release() is
 likely going to happen in response to very different UI events or IO
 events, it makes it fairly easy to accidentally have unbalanced calls.

 Consider for example a lock which is released either when a video
 reaches its end, when the user presses the pause button, or when the
 user close the dialog in which the video is rendered. It seems quite
 easy to end up with a race where if the user close the dialog right
 when the video ends, that release() would get called twice. Or if the
 user pause the video first and then close the dialog that release()
 would get called twice.

 Seems to me a declarative solution (like CSS) might be appropriate.

 @media screen {
 video:playing {
 wake-lock: display 15s;
 }
 }

 article.recipe:target {
 wake-lock: display;
 }

That's not a terrible idea.  The CSSWG is generally hesitant to put
behavior-altering things in CSS, but some bleed-through is fine, and
this can be argued as an aspect of appearance.

This solves the GC and locking issues (the latter by delegating state
management to CSS, which everyone already knows to use).

~TJ

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

[Tab Atkins Jr.]

On Mon, Aug 18, 2014 at 4:21 PM, Kornel Lesiński kor...@geekhood.net 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. WakeLocks are especially 
 problematic in this regard, as a leaked lock won't cause any immediate 
 problems for the developer, so this type of bug can easily go unnoticed.

 So I think lifetime of WakeLocks needs to be attached to something visible to 
 make failure to release the lock immediately obvious.


 In case of screen lock it's especially easy: the whole purpose of this lock 
 is to keep something visible on screen, so we can require that something to 
 be explicitly connected to the lock.

 For example if I were creating a widget that displays a presentation on the 
 page, I could attach the screen lock to the canvas or svg element that 
 holds the presentation:

 new navigator.ScreenLock(myCanvas);

 and if the canvas was removed from the document or hidden in any way, then 
 the browser could turn the screen off as usual, and I wouldn't have to do 
 anything!

 It's nearly impossible to forget to remove a visible DOM element from the 
 document — the mistake is likely to be quite obviously visible. If screen 
 lock lifetime was dependent on visibility of a DOM element, then it would 
 also be very hard to leak the lock without noticing it!

 (that's a variant of wake-lock:display CSS proposal, but less explicitly 
 dependent on CSS).

Good, but you lose the ability to key the wake-lock to
Selectors-exposed UA state (like video:playing), or directly to your
app's own state (via some class that gets set/removed by your app at
some point in its lifecycle).

But if the CSS part is distasteful, I agree that this works reasonably
well - there is *absolutely no reason* to screenlock based on an
element that's not visible on screen.

 With CPU lock it's less clear cut. I think tying it to a notification may be 
 a good idea. Alternatively, perhaps the lock itself could be an instance of 
 the progress element that author is supposed to insert to the document? ;)

Just pass a promise to the CpuLock constructor, and have it
auto-release when the promise is settled?  You'll generally be
CPU-locking to wait for some operation to finish, and a lot of those
types of operations vend promises these days (or will in the future).

~TJ

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

[Tab Atkins Jr.]

On Mon, Aug 18, 2014 at 5:10 PM, Domenic Denicola
dome...@domenicdenicola.com 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 
 top of? A lot of the ideas here seem to be trying to create the perfect, 
 developer-friendly, foolproof API. Some of them seem quite clever too, tying 
 to page visibility and the like. But all of them could be built, as 
 libraries, on top of a global request/release. That way users could get 
 reference counting if they want that, visibility-based locking if they want 
 that, promise-based locking if they want that, timeouts if they want those, 
 or even just not do any of those if their use case is simple enough that it 
 doesn't warrant anything more complicated than what they are already doing on 
 existing platforms.

 We don't need to solve Hard Problems in Programming (TM) before we expose a 
 wake lock API. Leave that as a subsequent step, which users can do, while we 
 move on to exposing more missing platform capabilities

Nope, doesn't work.  You can't build anything more complex on top of a
simple request/release (or a boolean, which is equivalent), because
any other library can come along and screw with the lock.  So, if we
want this to be extensible, we still need to design it in a localized
way so that you can have multiple independent locks.

If we did that, we *could* then layer a visibility/promise-based thing
on top as an auto-release mechanism for a specific lock.  But you've
still got to solve at least one problem correctly.

~TJ

Re: [whatwg] Question on server side api

[Tab Atkins Jr.]

On Aug 4, 2014 7:08 PM, L2L 2L emanuelal...@hotmail.com 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 over your server beyond sending requests for
content and hoping the server responds.

To do anything server-side, you want to learn a server-side language, like
Node.js, PHP, or frankly anything, as long as you can find a framework you
like.

~TJ

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

[Tab Atkins Jr.]

[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 anewpage.me...@gmail.com wrote:

 Problem
 ===

 It's difficult to know when an unsupported property was set for any
arbitrary
 element, and manually sifting through stylesheets isn't very easy.

 This makes polyfilling CSS harder than it needs to be.

 Strawman
 ===

 The endgoal is to easily get a NodeList containing elements that have a
 particular invalid/unsupported property applied.

 Suggestion 1: Dictionary
 ---

 Object populated with information about elements that have a rejected CSS
 property applied.  It updates continuously to reflect the app's most
 current state.

 document.rejectedCSSProperties = {
   rejectedPropertyName: NodeList,
   ...
   ...
 };

 This, combined with Object.observe, would allow authors an extensible way
to
 handle unsupported CSS.

 Suggestion 2: Query Method
 ---

 document.getElementsByRejectedProperty('foo-bar');

 This is the most direct solution.  Maybe more difficult to
implement/maintain
 vendorside.  Should return live NodeLists, a la getElementsByClassName.

 Suggestion 3: Event
 ---

 document.oncsspropertyrejected = function(event) {
   element.property // foo-bar
   event.elements // NodeList
 };

 Kind of similar semantically to the solution in Suggestion 1, but in a
 more traditional format.  I prefer Suggestion 1, as it offers a
 centralized registrar of rejected properties.

CSS very intentionally does not expose invalid properties, to protect our
ability to extend CSS in the future.

Instead, we are adding custom properties with a special syntax that
guarantees no future conflicts will occur: any property name that starts
with two dashes is a custom property, and will be preserved in the cssom
and not otherwise processed by CSS.

The first iteration of custom properties is defined in 
http://dev.w3.org/csswg/css-variables. This is a simplistic variant,
exposing only the portion of vision properties that is needed for
variables, but the CSS Extensions spec 
http://dev.w3.org/csswg/css-extensions will define a more complete variant
of the feature, including the ability to easily determine what elements
have a custom property applied to them, and when it changes.

~TJ

Re: [whatwg] Questions about the Fetch API

[Tab Atkins Jr.]

On Tue, Jul 8, 2014 at 11:35 AM, Juan Ignacio Dopazo
jdop...@yahoo-inc.com wrote:
 - And more importantly, why does fetch() return a PromiseResponse 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 it, rather than, say, making the object itself
asynchronous in some way.)

~TJ

Re: [whatwg] brand-color meta extension

[Tab Atkins Jr.]

On Mon, Jun 30, 2014 at 9:23 AM, Tao Bai michael...@google.com 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 read late.
Since the first valid one gets used, if you put one in the head the
browser doesn't have to worry about parsing to the end just in case
someone put another declaration at the bottom of the document.

meta elements already have authoring conformance criteria requiring
them to be in the head when they're not being used for Microdata.

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

On Fri, Jun 27, 2014 at 2:11 PM, David Carlisle dav...@nag.co.uk 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 a WG.

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 9:11 AM, Ian Hickson i...@hixie.ch wrote:
 On Tue, 24 Jun 2014, Robert O'Callahan wrote:

 !DOCTYPE HTML
 svg
 span id=s/span
 div id=i/div
 the elements s and i are put in the HTML namespace already.

 As siblings of the svg element, though, not descendants.

 This was required to get some level of compatibility with deployed content
 while still allowing svg in HTML. There was content out there that, for
 reasons that defeat me, had svg start tags (but not end tags). If we had
 not introduced this limited trap door out of the foreign lands (it's a
 hard-coded list of tag names that bail out in this way), it would have
 caused the pages to be blank from the svg start tag to the end.

That's assuming that HTML content doesn't render in SVG (or that the
html tagnames are parsed as unknown SVG elements).  Under the
proposals for defining an SVG layout model that integrates properly
with the other CSS layout models, the content would be displayed.

(The current proposal would place all the direct HTML children of SVG
elements on top of each other, similar to abspos, but grandchildren
would render normally, in a CSS layout model.)

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 9:44 AM, Anne van Kesteren ann...@annevk.nl wrote:
 On Thu, Jun 26, 2014 at 6:35 PM, Tab Atkins Jr. jackalm...@gmail.com 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 render normally, in a CSS layout model.)

 Isn't content outside of svg clipped though?

Ugh, yeah, svg is overflow:hidden by default.

How many of these crazy sites were there? I'd hate to flounder on such
an important change due to just a handful of idiotically-authored
sites.  Better integration of HTML and SVG (and blocking any further
element copying beyond the four existing elements) is really
important.

~TJ

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

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 10:35 AM, Marcos Caceres w...@marcosc.com 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).

 # Overview

 The browser will use this brand color when distinct color is needed, i.e. it 
 could be used as Web App’s title bar.

 Other browsers have similar features, but each defined as its own specific 
 meta tag, IE uses mapplication-navbutton-color, Safari’s is 
 apple-mobile-web-app-status-bar-style, they are all similar with brand-color, 
 but have a little different usage.

 # Syntax

 meta name=brand-color content=#ff

 The content attribute can be any value defined in css color specification 
 http://www.w3.org/TR/css3-color/ , the value might be adjusted by browser if 
 it is not proper for display, i.e. extremely bright. the leading and trailing 
 whitespace (defined in http://www.w3.org/TR/html401/struct/text.html) is 
 permitted.
 The brand-color meta tag must be in head element, If there are multiple 
 brand-color meta tags in head element, first one takes effect.
 Brand color could be changed by script, browser shall respect this change.

 Relevant issues/discussions:
 https://bugzilla.mozilla.org/show_bug.cgi?id=1013913
 https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nzRY-h_-_ig/IeXq74xUWzkJ

Here's a first crack at a better spec:

# Overview

The 'brand-color' meta extension defines a suggested color that
browsers and OSes displaying this page SHOULD use if they customize
the display of individual pages in their UIs with varying colors.

For example, a browser might color a web app's title bar with the
specified 'brand-color' value, or use it as a color highlight in a
task switcher.

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 Safari.
Authors MUST NOT use the proprietary variants of this meta extension.
User agents that support proprietary variants of this meta extension
must, if brand-color is specified, use brand-color for these
purposes, and ignore any proprietary variants.

# Syntax

Example:
meta name=brand-color content=#ff

The content attribute for the brand-color meta extension can take
any valid CSS color.

To dfnfind a page's brand color/dfn:

1. Let varcandidate elements/var be a list of all the
brand-color meta elements on the page, in document order.
2. For each varelement/var in varcandidate elements/var:
1. Parse a component value from varelement/var's content
attribute value. [[css-syntax]]
2. Attempt to parse the result as a CSS color.  If it succeeds,
return the parsed color.

Note: This implies that the first successfully parsed brand-color
meta element defines the page's brand color. Any further
brand-color meta elements have no effect.

If brand-color meta elements are added or removed from the page, or
have their content attribute changed, user agents MUST find the page's
brand color again.

When using the page's brand color, user agents MAY adjust the color
in UA-defined ways to make it more suitable for particular uses.  For
example, if a UA intends to use the brand color as a background and
display white text over it, it may use a darker variant of the brand
color for that purpose, to ensure adequate contrast.

~TJ

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

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 10:57 AM, Tab Atkins Jr. jackalm...@gmail.com 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 Safari.
 Authors MUST NOT use the proprietary variants of this meta extension.
 User agents that support proprietary variants of this meta extension
 must, if brand-color is specified, use brand-color for these
 purposes, and ignore any proprietary variants.

In another thread, Hixie asks why we don't just standardize these
proprietary variants.  I think because they're horridly named is a
sufficient answer, but there's a weaker proposal inside of that which
I think is potentially valid: should we define that
msapplication-navbutton-color and
apple-mobile-web-app-status-bar-style are required-support variants?

This requires a bit of additional parsing work, but it's not a big deal:

* msapplication-navbutton-color only allows named and hex colors.
* apple-mobile-web-app-status-bar-style appears to accept the values
default, black, and black-translucent, which we can define as
meaning, respectively, that the page has no brand color, that the
brand color is black, or that the brand color is rgba(0,0,0,.5)
(spitballing here, if someone can provide the real alpha that would be
great).

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 10:40 AM, Chris Lilley ch...@w3.org 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 anything but I never took the tags out because they
 were harmless test page from years ago.

Well, I remember one in particular was the page of some soccer club,
and definitely not a test page.  That said, I'm comfortable with
breaking a small number of sites for this change.

~TJ

Re: [whatwg] Proposal: defining script as link rel=script href=actualwaytoscript

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 12:09 PM, Boris Zbarsky bzbar...@mit.edu 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 style doesn't autoclose head, in
 fact; I thought it did.

style is explicitly one of the five elements allowed in head.
It's always been non-conforming for authors to put it in body.

~TJ

Re: [whatwg] brand-color meta extension

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 1:24 PM, Mathias Bynens mathi...@opera.com 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 (the other one being `input type=color 
 value=foo`).

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
color.

~TJ

Re: [whatwg] brand-color meta extension

[Tab Atkins Jr.]

On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens mathi...@opera.com wrote:
 On 26 Jun 2014, at 22:24, Mathias Bynens mathi...@opera.com 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 (the other one being `input type=color 
 value=foo`).

 Actually, the way it’s currently specced it wouldn’t be a parsed as a simple 
 color value nor as a legacy color value. It should probably be one or the 
 other (rather than introducing a third, new way to parse color values). 
 https://github.com/whatwg/meta-brand-color/issues/1

Well, the third way is as CSS, which already exists in the platform.

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

[plain-text email, please. HTML emails rarely survive
plain-text-ification unscathed.]

On Mon, Jun 23, 2014 at 11:35 PM, Gavin Kistner phr...@me.com wrote:
 On 24 Jun 2014, at 05:25, Robert O'Callahan rob...@ocallahan.org wrote:
 On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:

 Allowing html directly in svg is definitely the right answer. Parsing
 shouldn't be too hard, and defining the layout model would be pretty
 trivial.

 For layout, we could do this:
 1) When an HTML element is a child of an SVG element, perform CSS layout of
 the HTML element treating the nearest SVG viewport as the containing block.
 Its user-space width and height become the width and height of the
 containing block in CSS pixels.
 2) Treat such HTML elements as position:relative.

 We should also support position:absolute. Given that this can then be
 changed, what happens for position:static? Ignored? Just flow within the
 school container?

 I agree that position:relative is a desirable default in this case, but if
 position:static can be supported then I (lightly) argue that a special case
 to change the default value inside SVG is a bad idea. It's more code, and
 less expected for end users.

Okay, changing my mind a little bit.  Giving more thought here, I
think we should:

1. Define that the SVG layout model is a thing.  svg elements
trigger it automatically, probably via display-inside: svg
!important; in the UA stylesheet.  (This allows display: whatever;
on svg elements to still work correctly, as it would only be able to
change display-outside.)

2. Other SVG elements propagate the SVG layout model.  This is maybe
via a display-outside:svg rule on svg|*:not(svg).  We can tweak
what approach we use here.

3. Everything in the SVG layout model is positioned relative to the
root of an SVG layout model, using x and y properties.

4. That's it.  Normal HTML elements use display:inline or
display:block or whatever, so they dont' propagate the model; they
position themselves via x/y, but their children lay out normally.

You can then use 'position' as usual if you want to abspos or
whatever, but given the standard position:static, x/y is where it's
at.

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

On Mon, Jun 23, 2014 at 9:35 PM, Dirk Schulze dschu...@adobe.com wrote:
 On Jun 24, 2014, at 5:25 AM, Robert O'Callahan rob...@ocallahan.org wrote:
 On Thu, Jun 19, 2014 at 4:33 AM, Tab Atkins Jr. jackalm...@gmail.com
 wrote:
 Yes, increasing the set of name-alikes between html and svg is absolutely
 not something we'll support. (I've unfortunately been out of the loop with
 the svgwg for a while, or else I would have prevented this from showing up
 in the first place.)

 Allowing html directly in svg is definitely the right answer. Parsing
 shouldn't be too hard, and defining the layout model would be pretty
 trivial.


 I think we should actually figure this out.

 I'm not an expert on the HTML parser, but it seems to me there's already
 some support for what we need. E.g. given
 !DOCTYPE HTML
 svg
 span id=s/span
 div id=i/div
 the elements s and i are put in the HTML namespace already.

 For layout, we could do this:
 1) When an HTML element is a child of an SVG element, perform CSS layout of
 the HTML element treating the nearest SVG viewport as the containing block.
 Its user-space width and height become the width and height of the
 containing block in CSS pixels.
 2) Treat such HTML elements as position:relative.
 3) Add x and y attributes to HTMLElement and have them map to left
 and top CSS properties. (There's a crazy legacy compat issue for
 HTMLImageElement.x/y but we can hack around that.)

 We will have the x, y properties. No need to map to left and right.

Yeah, this is part of the general SVG/CSS convergence effort, already
approved and under way.

 4) Add a transform attribute to HTMLElement and have it map to the
 transform CSS property.

 In this case we should think about making transform a presentation attribute 
 in general for HTML and SVG.

That's effectively what it would do, yes.

 #3 and #4 are optional, there are pros and cons to having them. Using the
 nearest SVG viewport in #1 is because other SVG container elements don't
 have a defined size (and we can't use getBBox because that depends on the
 layout of the children).

Yes, using the nearest svg was my plan as well.

~TJ

Re: [whatwg] SVG cloning elements from HTML5

[Tab Atkins Jr.]

On Jun 18, 2014 6:00 AM, Robert O'Callahan rob...@ocallahan.org 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 keep this making sense as SVG and
 HTML5 evolve, e.g. as new attributes get added to HTML5 elements. It will
 be easy to change HTML5 in ways that break this SVG spec (and possibly
vice
 versa). SVGIframeElement implements HTMLIFrameElement creates a multiple
 inheritance situation that I don't think any engine would really want to
 implement, even if it made sense, which I don't think it does. I'm pretty
 sure no-one who actually works on HTML5 has approved of this. Yes, it's
 only in a draft, but people are already taking that as a cue to start
 implementing. I think we need to take a step back from this, figure out
 what the goals are and then work together on solving them the right way.

 It seems to me that if we possibly can, we should solve this by reusing
the
 actual HTML elements so much less spec synchronization is needed. We
 probably should find a way to support actual HTML elements as direct
 children of SVG elements with no intervening foreignObject. We should
 make sure the parser can handle that too, at least for a whitelisted set
of
 elements.

Yes, increasing the set of name-alikes between html and svg is absolutely
not something we'll support. (I've unfortunately been out of the loop with
the svgwg for a while, or else I would have prevented this from showing up
in the first place.)

Allowing html directly in svg is definitely the right answer. Parsing
shouldn't be too hard, and defining the layout model would be pretty
trivial.

~TJ

Re: [whatwg] Proposal: Inline pronounce element

[Tab Atkins Jr.]

On Tue, Jun 3, 2014 at 3:26 AM, Daniel Morris
daniel+wha...@honestempire.com 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 of having a way to represent the
 pronunciation of words on a web page.

 There is currently no other text-level semantic that I know of for
 pronunciation, but we have elements for abbreviation and definition.

 As an initial suggestion:

 pronounce ipa=“ˈaɪpæd”iPad/pronounce

 (Where the `ipa` attribute is the pronunciation using the
 International Phonetic Alphabet.)

 What are your thoughts on this, or does something already exist that I
 am not aware of?

This is already theoretically addressed by link rel=pronunciation,
linking to a well-defined pronunciation file format.  Nobody
implements that, but nobody implements anything new either, of course.

~TJ

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

[Tab Atkins Jr.]

On Wed, Apr 30, 2014 at 7:32 AM, Glenn Maynard gl...@zewt.org 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 would override [hidden].  What we really need is a CSS
 property that only sets whether the element is visible or not and nothing
 else, like visible: false.  That way, the only way [hidden] gets
 overridden is if you're actually setting the visibility style.

Mind bringing this up in www-style?  My thinking in that design is
that display-box controls whether an element generates boxes at all,
which seems consistent with including the 'contents' value.  But if it
seems useful to have a property dedicated to literally just hiding the
element, we can see about rejiggering things.

~TJ

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

[Tab Atkins Jr.]

On Wed, Apr 30, 2014 at 2:32 PM, Ian Hickson i...@hixie.ch 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 'opacity:0' ?

Yes.

~TJ

Re: [whatwg] summary/details - proposal

[Tab Atkins Jr.]

On Tue, Apr 8, 2014 at 5:25 AM, Steve Faulkner faulkner.st...@gmail.com 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 CSS and Js and ARIA is unfortunate, and as you said
 yesterday

I still don't understand.  Do you think that what Hixie is saying
(about clicking on non-interactive text in summary toggling the
details) is wrong?

The behavior that Hixie describes is roughly what implementations do
today.  In Blink, clicking on any bare text in the summary toggles
the details, while clicking on an input does not.  However, Blink
current behavior with label is different - it basically ignores the
presence of the label, as far as I can tell, and still toggles the
details even if the label is redirecting the click to an input.

I would strongly object to any suggestion that summary should only
toggle details when you click on the disclosure triangle, unless you
add some additional markup like label.  That would be terrible UI.

~TJ

Re: [whatwg] new constructor method for Path2D

[Tab Atkins Jr.]

On Mon, Mar 10, 2014 at 11:38 AM, Justin Novosad ju...@google.com wrote:
 On Mon, Mar 10, 2014 at 2:14 PM, Rik Cabanier caban...@gmail.com wrote:
 On Mon, Mar 10, 2014 at 11:07 AM, Joe Gregorio jcgrego...@google.com
 wrote:
  What part is slow, the decoding and re-encoding, or is just always the
  encoding step
  that is slow?

 It's decoding/re-encoding of an already constructed path.

 Can't the implementation just perform that work lazily the first time the
 path is rasterized, and retain the cached result for subsequent use of the
 path object?

This is also my question.  Given that generating a path for a
particular context isn't a magic bullet *anyway* (because the details
of the context can change), I don't understand why caching isn't the
answer.

~TJ

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Tab Atkins Jr.]

On Thu, Feb 20, 2014 at 7:25 AM, Ashley Gullen ash...@scirra.com wrote:
 We're building a browser-based P2P multiplayer engine on top of WebRTC
 DataChannels. You can try out our work-in-progress here:
 http://www.scirra.com/labs/multiplayer/test1/

 The first player in to a room is assigned the host, and all other
 subsequently joining peers connect to the host with WebRTC DataChannels and
 start exchanging game data. Like all responsible HTML5 games, it runs based
 on a requestAnimationFrame loop.

I think this is your problem.  rAF isn't a replacement for setTimeout,
it's a variant designed to better solve the timer problem *when you
want to be synced to the screen*.

If you're doing network-management work, that has nothing to do with
the screen refresh rate, and shouldn't be associated with it.  Just
run a normal setTimeout loop instead.

(If people used rAF for what it was *intended* for, we could probably
have stopped firing it *entirely* when the window isn't visible.
Instead, we had to compromise with the 1s refresh rate instead.)

~TJ

Re: [whatwg] Proposal: requestBackgroundProcessing()

[Tab Atkins Jr.]

On Thu, Feb 20, 2014 at 8:23 AM, Ashley Gullen ash...@scirra.com 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.

All right, proceed with your request. ^_^

~TJ

Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS

[Tab Atkins Jr.]

On Wed, Jan 22, 2014 at 1:51 PM, Daniel Holbert dholb...@mozilla.com wrote:
 Hi folks,

 Boris Zbarsky and I ran across a not reflecting reality issue in the
 WHATWG HTML spec.

 The spec currently defines the rendering of the br element as follows:
  # br { content: '\A'; white-space: pre; }
 Source:
 http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1

 This CSS implies that br's rendering could be customized by CSS, which
 in practice (in the browsers that I tested[1]) is not actually the case.

We talked this over in the CSSWG meeting, and came up with a proposal
for non-magical styling that is still very close to current behavior
in all browsers:

br {
  display-box: contents;
  content: \A;
  white-space: pre;
}

This lets you adjust the size of the br with text-styling
properties, and use display:none to hide it entirely.  Any/all of
these can be set to !important if necessary for compat.

~TJ

Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS

[Tab Atkins Jr.]

On Tue, Jan 28, 2014 at 1:04 AM, Elliott Sprehn espr...@gmail.com wrote:
 On Thu, Jan 23, 2014 at 10:54 AM, Daniel Holbert dholb...@mozilla.comwrote:
 On 01/23/2014 03:16 AM, Stewart Brodie wrote:
  [2] I only noticed one rendering difference -- IE11 honors border on
  br, unlike the other browsers that I tested. (It still doesn't honor
  e.g. display/width/height, though.)
 
  I get different results on your test case for the bottom two tests.  In
  Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26
  there isn't.

 Yeah -- sorry, I thought up those last two testcases (applying float
 and position:absolute to br) a bit later, after I sent my initial
 email. (which is why I didn't mention them as a rendering difference)

 So, the position  float properties do represent a little bit of
 style that Gecko honors on br (but not Blink/Presto; not sure about IE).


 Blink treats br (conceptually) like a subclass of Text, there's nothing
 to style because it's just a run of text with a forced break.

Okay, so FF treats it as an element with a magical 'display' type, and
Chrome treats it as equivalent to text. These are observably
different.  Are either of you willing to switch to the other's
behavior?  That would make my life way easier, thanks.

~TJ

Re: [whatwg] 'hidden' as resources control (Was: Simplified picture element draft)

[Tab Atkins Jr.]

On Thu, Jan 23, 2014 at 6:13 PM, Bruno Racineux br...@hexanet.net wrote:
 On 1/22/14 6:07 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/22/14 8:14 PM, Bruno Racineux wrote:
 Meanwhile, is there a way in which all vendors can prevent their
 pre-loaders from preloading (and loading at all for that matter) any
img
 that has either: An html5 hidden attribute

This is feasible.

 or display:none

This is not really.  The preload scanner has no idea bout styles.

 Then how come it is the case right now for both:

 object style=display:none data=image.png

 As well as:

 head
 style
 .dn { display:none; }
 /style
 head
 body
 object class=dn data=image.png
 body

 Not only the pre-loader doesn't load the data-src
 but image.png doesn't actually load at all.

You're assuming that object preloads at all.

Boris isn't saying that making the preload scanner care about styles
is a bug, he's saying it's *impossible* (unless your preload scanner
triggers so late as to be a literally-just-before-load scanner).

~TJ

Re: [whatwg] Simplified picture element draft

[Tab Atkins Jr.]

On Wed, Jan 8, 2014 at 9:18 AM, Maciej Stachowiak m...@apple.com wrote:
 On Dec 31, 2013, at 7:17 AM, Yoav Weiss y...@yoav.ws wrote:
 On Mon, Nov 25, 2013 at 5:33 PM, Adam Barth w...@adambarth.com wrote:
 Is there an editor's draft or some other relatively self-contained
 write-up that I could review?

 Tab has rewritten the picture spec to match the latest proposal. You could
 review it at http://picture.responsiveimages.org/

 This approach seems cleaner than src-n. I'll try to read it in more detail, 
 but a few initial comments:

 - Is there any reason not to allow the sizes= attribute and the extended 
 definition of srcset= on img as well as source? It seems like the 
 picture wrapper is not helpful in cases where you only use one source 
 element.

Nope, no reason other than I was trying to minimize initial changes in
the spec.  I'm totally happy to add it, for the reason you list, and
so that an early implementation of just img srcset will be
compatible with a fuller picture implementation.

 - It seems this draft allows arbitrary media queries, with only a subset 
 expected to give best performance (by correctly informing the preload 
 scanner). In my opinion, this is worse than the alternative of only 
 supporting the media queries that could plausibly be integrated with preload 
 scanning. Creating a programming interface with a performance cliff - a 
 point beyond which performance suddenly gets significantly worse for what 
 seems like a small incremental change - is generally a bad idea. And the use 
 cases for fully general media queries seem much more speculative than the 
 ones for the simplified subset.

The set of MQs that can be done on the preloader thread seems
ill-defined and potentially growing.  Even within the set that the
spec currently requires, we've gotten feedback that those MQs are
possible in some cases but not others (within an iframe you can't tell
what the viewport dimensions are until the outer document has finished
initial layout).

~TJ

Re: [whatwg] Simplified picture element draft

[Tab Atkins Jr.]

On Wed, Jan 8, 2014 at 9:47 AM, Yoav Weiss y...@yoav.ws wrote:
 On Wed, Jan 8, 2014 at 6:18 PM, Maciej Stachowiak m...@apple.com wrote:
 - It seems this draft allows arbitrary media queries, with only a subset
 expected to give best performance (by correctly informing the preload
 scanner). In my opinion, this is worse than the alternative of only
 supporting the media queries that could plausibly be integrated with preload
 scanning. Creating a programming interface with a performance cliff - a
 point beyond which performance suddenly gets significantly worse for what
 seems like a small incremental change - is generally a bad idea. And the use
 cases for fully general media queries seem much more speculative than the
 ones for the simplified subset.

 I'm not opposed to having a white-list of performance-safe authorized
 media queries, and extending that list in the future if necessary, but we
 need to make sure that it's extensible without causing the content to break
 in browsers where the new MQs are not supported. As far as I can tell, the
 current syntax can support this.

Right.  We can't just ignore the MQ, as that's unfriendly.  We could
maybe ignore the source, but that feels like too much.  Having it
evaluated on the main thread is slower, but it's guaranteed to *work*
in older browsers, which is nice.  And, as previously stated, *every*
MQ beyond resolution is preloader-unfriendly in at least some cases.

I'd like to avoid making this complicated for authors as much as
possible.  Having to worry about if legacy browsers will display an
image more slowly is much less troublesome than wondering if legacy
browsers will display it at all; in most cases, you don't have to
worry about it at all, because preloading is a nice benefit but not a
necessity.

Note, too, that though the full set of MQs is only for niche cases, I
can certainly come up with reasonable cases nonetheless, particularly
as we introduce new device-capability MQs.  For example, you could
switch from a GIF to a still picture based on the updates MQ that
we're considering adding, or use a higher-contrast version based on
whatever MQ we end up developing for detecting high-contrast needs.
Disallowing these entirely just means that either devs will use JS to
switch their images (then why did we spend all this effort on a
markup-based solution?) or they just won't cater to those needs at
all.

~TJ