[whatwg] Relative positioning in the top layer
The Fullscreen spec says, for an element in the top layer: "If its specified position property is static, it computes to absolute."[1] I think this is to make top layer elements out of flow. But then shouldn't position 'relative' also compute to 'absolute'? [1] http://fullscreen.spec.whatwg.org/#new-stacking-layer
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky wrote: > Adam, thank you for taking the time to put this together. I really > appreciate it. There are lots of things here where we can converge behavior > no matter what happens with other pieces of the platform. > > On 1/9/13 5:58 PM, Adam Barth wrote: >> >> Generally speaking, I'd recommend exposing as few things across >> origins as possible. > > Yes, agreed. For what it's worth, I believe Gecko recently made history not > accessible cross-origin anymore, so with any luck you'll be able to make > this change too if desired... Do you have a link to the bug where that change was made? It's something I would definitely like to do if compatibility permits. We'd probably start with a measurement experiment... >> 6) In addition, the following APIs have extra security checks. All >> these APIs return a Node. Before returning the Node, they check >> whether the Node's document's origin is the same origin as the script >> calling the API. If not, they return null instead of the node. (We >> could potentially throw an exception here, but I'm just describing >> what WebKit does, not what I think the optimum design is.) > > Returning null for these is probably fine. I think I'd support making this > list of things return null cross-origin. Just to check, do you make this > determination based on the origin or the effective script origin (in spec > terms)? The effective script origin. Adam
Re: [whatwg] Sentence structure
On Thu, 10 Jan 2013, Thomas A. Fine wrote: > On 1/10/13 11:36 PM, Ian Hickson wrote: > > I don't know if the use cases justify adding a feature to CSS, but > > I'll let the CSS editors and browser vendors be the judges of that. > > :-) > > > > The CSS spec is discussed on the www-st...@w3.org list. > > Sorry then, I was under the impression that WHATWG covered a broader > spectrum than just the HTML piece. We currently cover the following specs: http://whatwg.org/specs Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sentence structure
On 1/10/13 11:36 PM, Ian Hickson wrote: I don't know if the use cases justify adding a feature to CSS, but I'll let the CSS editors and browser vendors be the judges of that. :-) The CSS spec is discussed on the www-st...@w3.org list. Sorry then, I was under the impression that WHATWG covered a broader spectrum than just the HTML piece. tom
Re: [whatwg] Sentence structure
On Thu, 10 Jan 2013, Thomas A. Fine wrote: > > I guess I was just way too long-winded. > > Buried in there were some good ideas, and I'm no longer strictly > advocating just a sentence tag. I read more about how things are > supposed to work, and I focused on what is needed in general terms, and > then as many different possible solutions and their pros and cons. > > I still think a sentence tag is a good idea, but I would now really > favor an approach that allows CSS to interpret a pair of spaces > following terminal punctuation directly as a sentence break, and then > provide a mechanism to format that directly. If I had to narrow things > down to just one choice rather than a spectrum of available approaches > it would be that one. > > It's practical for content developers, straightforward to implement, can > be easily applied to previously generated content, and does not "ugly" > up the HTML (in fact the HTML wouldn't even change at all, only a tiny > bit of CSS would be added). It's not ideal for semantic sentence > detection, but is at least a significant improvement there. I don't know if the use cases justify adding a feature to CSS, but I'll let the CSS editors and browser vendors be the judges of that. :-) The CSS spec is discussed on the www-st...@w3.org list. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Sentence structure
I guess I was just way too long-winded. Buried in there were some good ideas, and I'm no longer strictly advocating just a sentence tag. I read more about how things are supposed to work, and I focused on what is needed in general terms, and then as many different possible solutions and their pros and cons. I still think a sentence tag is a good idea, but I would now really favor an approach that allows CSS to interpret a pair of spaces following terminal punctuation directly as a sentence break, and then provide a mechanism to format that directly. If I had to narrow things down to just one choice rather than a spectrum of available approaches it would be that one. It's practical for content developers, straightforward to implement, can be easily applied to previously generated content, and does not "ugly" up the HTML (in fact the HTML wouldn't even change at all, only a tiny bit of CSS would be added). It's not ideal for semantic sentence detection, but is at least a significant improvement there. tom
Re: [whatwg] Sentence structure
On Thu, 10 Jan 2013, Thomas A. Fine wrote: > > Use Cases: > 1. Formatting sentence spacing to approximate the look of > almost all books in English from 1650-1950. This is possible today, using . Unless approximating the formatting of a small minority of old books becomes much more common than it is now, this use case probably doesn't justify using a dedicated element. > 2. Formatting sentence spacing because it is very likely an > aid to scanning text, and there are some indications that it > is helpful for new readers, readers learning a new language, > and readers with visual scanning issues and other learning > disabilities. Browsers can do this without markup (sentences are detectable by some relatively simple heuristics), so this wouldn't justify adding a markup-level feature. Incidentally, do you have any research to support this claim? My understanding is that in practice the double-spacing at the end of sentences is considered an antiquated practice that doesn't actually help with reading much, certainly not as much as slightly increased line spacing, clear punctuation, and the like. > 3. Formatting sentence spacing because I like it that way. This is possible today, using . Unless your preference here becomes much more common than it is now, this use case probably doesn't justify using a dedicated element. > 4. Clarifying sentence boundaries would be an aid in machine > translation software. Do you have any evidence supporting this? I've spoken with engineers who work on machine translation software and while they've certainly had requests (whence the "translate" attribute), they've never asked for a way to mark up sentences. > 5. Clarifying sentence boundaries would be an aid to screen > readers to help provide correct inflection. Screen readers must have excellent sentence ending detections regardless of what features we provide, because most Web pages (and there are trillions already) don't include such markup. So adding an element would not solve this problem. Since the use cases do not currently support adding an element for this purpose, I have not added the element to the language. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Sentence structure
[Apologies to those who read public-html or www-style at w3.org where I've raised these issues (although this is more comprehensive). The process for modifying HTML is way more complicated than it use to be, and I'm still trying to figure out all the parts and the best approach.] HTML needs support for identifying sentence structure. Use Cases: 1. Formatting sentence spacing to approximate the look of almost all books in English from 1650-1950. 2. Formatting sentence spacing because it is very likely an aid to scanning text, and there are some indications that it is helpful for new readers, readers learning a new language, and readers with visual scanning issues and other learning disabilities. 3. Formatting sentence spacing because I like it that way. 4. Clarifying sentence boundaries would be an aid in machine translation software. 5. Clarifying sentence boundaries would be an aid to screen readers to help provide correct inflection. When it comes to the formatting use cases, there are a huge number of people who currently use two spaces between sentences already, even in web content where it currently is wasted. Some significant portion of these people are likely to be interested in sentences formatting if such a feature was available in a practical form. As for machine-parsed uses, it's not actually my field, so I'm not sure how helpful it would be, only that it would be helpful to some degree. In my limited experience with text-to-speech, sentence inflection errors are usually a noticeable problem. Existing practices, with some obvious pluses(+) and minuses(-): * The most popular recommendation on the web is to use . + Many people are familiar with it. - Not so fun to type. - Only the non-collapsing aspect is needed, the non-breaking aspect interrupts line breaks and creates uneven justification (left and right). - No fine-grained or dynamic control that CSS could provide. - Not really so useful for machine translation of screen readers as it doesn't eliminate ambiguity. * Use other space entities. + Doesn't have the justification problem of . + Allows some degree of fine control with different space sizes. - There exists no space entity which is the same size as a space and which breaks but doesn't collapse. - Many content creators are not aware of these entities. - Not really so useful for machine translation of screen readers as it doesn't eliminate ambiguity. - Still not as fine-grained as a CSS solution and no dynamic control. * Use spans to wrap sentences (not commonly used). - Very tedious. + Allows fine-grained and dynamic control through CSS. - Clean CSS for formatting is not obvious (e.g. some recommendations say to use the box model, which disrupts line breaking and creates uneven margins). * Set white-space to pre-wrap (not commonly used). + Very simple for content creators. - Doesn't provide unambiguous sentences to machine parsers. - Pre-wrap honors new lines which may be undesirable to some authors [why isn't there a white-space option that preservers spaces but not newlines?]. - No fine-grained or dynamic control. Possible improvements, with some obvious pluses(+) and minuses(-): * Detect sentences from text with an off-the-shelf algorithm. + Works on all existing content. - Available algorithms are some combination of unreliable and expensive. - Content creator doesn't have any control over what the algorithm will decide is or is not a sentence. Some sort of tag or entity could be used only for exceptions but again, the content creator wouldn't know where the exceptions might occur without a specified algorithm. * CSS setting that tells the parser that two spaces after terminal punctuation can be trusted as a reliable method of detecting sentences without ambiguity. + Would work immediately for some existing content. + By far the simplest solution for content creators. + Gives content creator full control. * Explicit sentence tag that surrounds each sentence (and some associated CSS to format it). + The most "traditional" solution. + The only solution here that fully marks the entire sentence, not just the end or gap so there is no extra processing to find the beginning of a sentence. (Consider this a minus on all the other approaches, even though I didn't list it.) - Very tedious to do by hand + A dedicated tag could spur implementation of HTML editors that mark the text for you. * Dedicated tag to mark the gap between sentences. - Somehow this just seems weird to me, a tag that's only purpose is to contain a space. + An easy substitution to make in an editor or post-processor. * New entity that marks the ends of sentences, or the gap b
Re: [whatwg] Canvas: compositing and blending operator as enumeration?
On Jan 10, 2013, at 8:10 AM, Rik Cabanier wrote:
>
>
> On Wed, Jan 9, 2013 at 10:36 PM, Dirk Schulze wrote:
>
>
> On Jan 9, 2013, at 9:29 PM, "Rik Cabanier" wrote:
>
>> Hi Dirk,
>>
>> the 'globalCompositeOperation' property takes the same syntax as the css
>> 'mix' so I don't think an enum will work.
>>
>
> I am not following. What does the CSS property have to do with the canvas
> attribute?
>
>
> See the spec:
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending
> For consistency, people wanted the same syntax for canvas and css.
>
That is fine for me. I am not asking for different values or keyword names :P
Dirk
>
>> Rik
>>
>> On Wed, Jan 9, 2013 at 6:18 PM, Dirk Schulze wrote:
>> Hi,
>>
>> After all the discussions about winding rules and the new introduced
>> enumeration for "nonzero" and "even odd", I wonder if the the compositing
>> and blending modes should be two enumerations as well.
>>
>> enum CanvasCompositingMode {
>> "source-over",
>> "source-in",
>> …
>> }
>>
>> and
>>
>> enum CanvasBlendingMode {
>> "normal",
>> "multiply",
>> ...
>> }
>>
>> This wouldn't actually change the behavior or definition a lot, but might
>> help to cleanup a bit. I am happy about other names if they are not good
>> enough.
>>
>> Greetings,
>> Dirk
>>
>
Re: [whatwg] Canvas: compositing and blending operator as enumeration?
On Wed, Jan 9, 2013 at 10:36 PM, Dirk Schulze wrote:
>
>
> On Jan 9, 2013, at 9:29 PM, "Rik Cabanier" wrote:
>
> Hi Dirk,
>
> the 'globalCompositeOperation' property takes the same syntax as the css
> 'mix' so I don't think an enum will work.
>
>
> I am not following. What does the CSS property have to do with the canvas
> attribute?
>
>
See the spec:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#canvascompositingandblending
For consistency, people wanted the same syntax for canvas and css.
>
> Rik
>
> On Wed, Jan 9, 2013 at 6:18 PM, Dirk Schulze wrote:
>
>> Hi,
>>
>> After all the discussions about winding rules and the new introduced
>> enumeration for "nonzero" and "even odd", I wonder if the the compositing
>> and blending modes should be two enumerations as well.
>>
>> enum CanvasCompositingMode {
>> "source-over",
>> "source-in",
>> …
>> }
>>
>> and
>>
>> enum CanvasBlendingMode {
>> "normal",
>> "multiply",
>> ...
>> }
>>
>> This wouldn't actually change the behavior or definition a lot, but might
>> help to cleanup a bit. I am happy about other names if they are not good
>> enough.
>>
>> Greetings,
>> Dirk
>
>
>
Re: [whatwg] `window.location.origin` in sandboxed IFrames.
On Thu, Jan 10, 2013 at 12:17 AM, Mike West wrote: > Adam explained that WebKit currently treats the 'origin' attribute as > the origin of the document's location, not the origin of the > document[1]. This is generally benign, but surprised me in the > sandboxed case. > > What should the expected behavior in this case be? Given the way that > MessageEvent sets the origin of a message from a sandboxed frame to > the string "null", that seems like a reasonable option here as well. > > WDYT? > > [1]: https://bugs.webkit.org/show_bug.cgi?id=106488#c1 Given that location.origin is defined by http://url.spec.whatwg.org/ once the dust of integrating URL into HTML settles, having URLUtils.origin reflect the Document's origin when URLUtils is implemented by Location would be very weird. If you want the origin of a Document we could introduce Document.origin I suppose. -- http://annevankesteren.nl/
