Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On 25.11.2010 15:55, Biju wrote: The request I put is NOT about whether you can make it PRETTY looking or not. The question is about why we are allowing website have something which is MODAL (ie, both window modal and tab modal https://bugzilla.mozilla.org/show_bug.cgi?id=59314) In my opinion a no website should have that much control over user interaction. Well, you just said it: Bug 59314! That alert()s, prompt()s and confirm()s are window-modal is only an implementation issue: Some years ago browsers implemented these prompts the most convenient way: By opening a native modal dialog. But right now broswer vendors realize that this isn't really the best solution - because of DOS attacks and simply because it doesn't make any sense. And as you already mentioned: Firefox landed tab-modal dialogs a few days ago. Opera already had them. Other browsers will follow. So, what is your issue?
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On 24.07.2010 02:33, Bjartur Thorlacius wrote: Wrong. Plain wrong. Kids who like to test stuff do things like this. I do agree though that the urlbar isn't the right place, there should be a different prompt for this kind of stuff. Probably disabled at compile time by default and accessible by recompile (or addon). Not everybody who executes JavaScript Code using the address bar is a Linux freak who knows how to compile a browser. This mustn't be a hard-accessible configuration option. I really don't like the idea of disallowing it totally. It should suffice to prompt the user whether he is sure he want's to execute the script.
Re: [whatwg] Headings and sections, role of H2-H6
On 01.05.2010 04:02, Boris Zbarsky wrote: On 4/30/10 2:08 PM, Nikita Popov wrote: I don't know whether I would be happy, if all headings in my document were shown *BIG*, 'cause I use h1 everywhere. I would much more appreciate them to be unstyled. (But this is only personal opinion.) Really? Given: This is a header This is some text after the header. The "unstyled" rendering you would see is: This is a headerThis is some text after the header. Yeah, you're right. This would be problematic. This does convince me, that using is not a good idea. I easily think that using h1 everywhere isn't semantically correct. Especially if the subsections (with their h1s) cannot be redistributed solely it does not make any sense. I'm not sure I follow. I wanted to say, that it does not make sense to me, to use a highest ranking heading in all sections, subsections, and subsubsubsections, especially if they cannot be used solely (out of context). But maybe you are right. The html5 spec is already blown up with stuff nobody will ever use (keygen?) enough. Amusingly enough, keygen is something I use once a year or so (when my user certificate expires), and something that MIT students need to use to, say, register for classes (or view their grades, deal with bursar's office stuff online, etc, etc). See https://ca.mit.edu/ca/certgen (though that will likely require a login... that you may not have). See http://ist.mit.edu/services/certificates for the various documentation. I do not deny, that keygen has it's use cases (the "nobody" was hyperbolic). I only think, that the use cases are *very* rare. It is overkill to introduce an HTML element therefore. It would be much more sane to provide a JS API (as Janos proposed.) [I would do it myself, but I have only very little knowledge on encryption.]
Re: [whatwg] The real issue with HTML5's sectioning model (was: "Headings and sections, role of H2-H6" and "Should default styles for h1-h6 match the outlining algorithm?")
On 30.04.2010 21:47, Greg Houston wrote:
On Fri, Apr 30, 2010 at 1:57 PM, Eduard Pascual wrote:
So, that's enough of a problem statement (at least for now). My
suggestion is to clean things a bit: consolidate the sectioning model
into a single element+attribute pair, like this:
stays as is.
becomes
becomes
becomes
becomes
I haven't been following this thread, but for just the styling aspect
of it, the same thing can be accomplished by adding a "section" class
to each of these elements:
I think this defeats all the purpose of the different sectioning
elements. They want to save code, not let you state the obvious by
class="section"
So that this...
h1 { styling for top-level }
section h1 { styling for second-level }
section section h1 { styling for third-level }
Becomes this:
h1
.section h1
.section .section h1
Regarding your proposal, if I wanted to style the following element
only, what would the CSS look like?
section[kind=aside]
or if you want to style all *containing* aside (kind="asid nav"):
section[kind~=aside]
Another option along the lines of your proposal, is you could still
have the same functionality without the kind="*" so that rather than
becomes
becomes
becomes
becomes
is treated as
is treated as
is treated as
is treated as
In this case nav, aside, article, and address are all types of
sections, and so any style added to a section is added to each of
these, with any style added to one of these specific elements
overriding the section style rules.
In both cases you lose the ability to apply CSS to a plain old section
that will not be automatically applied to the other elements. A third
option is to have a quasi-element that refers to all of these but is
never actually used in the HTML. It would just be a tool for CSS and
outlining algorithms. I can't think of a good name for it, but for
example, "sectional" could reference all of the following and anything
else one might thing should go in this list: section, nav, aside,
article, and address. Now you can style section without having to
override that styling in nav, aside, article, and address.
h1
sectional h1
sectional sectional h1
I think this last option might solve the problems without changing the
current html or css, and would simply add a hook for outlining
algorithms and other use cases where you want a clean way to get a
particular element at a particular depth.
Just some thoughts.
G.
I think introducing pseudo-elements that actually do not exist is a step
in the wrong direction. It tries to solve a side effect of the problem,
instead of solcing the problem at it's root.
@Eduard: I thing your concept is quite good. I only do not like @kind.
@type (as you already said) would be more intuitive.
PS: Mozilla solved the exponential problem using :-moz-any(), others
will probably do it this way, too.
Re: [whatwg] Headings and sections, role of H2-H6
On 30.04.2010 16:11, Boris Zbarsky wrote: On 4/30/10 8:02 AM, Nikita Popov wrote: I personally prefer using and do not see, why always using may be better. If you're the only author, sure (maybe; see below). If you're one of several co-authors on a document, with sectioning structure in flux, and you're supposed to produce one of the sections but don't know how deeply nested your section will be in the final document, then how are you supposed to use correctly? Yeah, I see. What would make much more sense, is to omit the rank fully, so only only has to write . Yes, and I'm fairly certain that's been discussed in the past. But already exists, and people already use it and the new uses will degrade gracefully in UAs not supporting the new spec text much better than uses of would. I don't know whether I would be happy, if all headings in my document were shown *BIG*, 'cause I use h1 everywhere. I would much more appreciate them to be unstyled. (But this is only personal opinion.) Beyond that, using instead of would even be more backwards compatible to the HTML 4 use of headings. But not to existing HTML4 UAs... As said above, I think it increases backwards compatibility by omitting all styles. But it depends on the case whether it's better to have only big titles or only unstyled titles. I easily think that using h1 everywhere isn't semantically correct. Especially if the subsections (with their h1s) cannot be redistributed solely it does not make any sense. would mark up a heading, does mark up an heading of highest rank. But maybe you are right. The html5 spec is already blown up with stuff nobody will ever use (keygen?) enough. In this case less is probably more.
Re: [whatwg] Headings and sections, role of H2-H6
I personally prefer using and do not see, why always using may be better. Furthermore I think that using in this case is quite irritating. The HTML 4.01 standard says the h1-heading to be most important, the HTML 5 standard defines it as having the highest rank. It is in my eyes unintuitive having only headings of highest rank in a document. (Yes, I know, that this isn't quite correct, but from the view of a simple html author who doesn't really care about outline algorithms, this is true.) What would make much more sense, is to omit the rank fully, so only only has to write . Rank of this title is to be found using the outline algorithm Yey, content! Furthermore this ensures that one can easily style a document that uses both the ed variant and the -ranked one without having an extra selector. Beyond that, using instead of would even be more backwards compatible to the HTML 4 use of headings.
[whatwg] Mistyping of title end tag causes white page
I noticed, that mistyping the ending title tag causes a white page and a title containing the whole source of the page (from the starting title tag on) in firefox3.6 with enabled HTML5 Parsing Algorithm. As I haven't read the the HTML5 Parsing Algorithm section, I don't know whether this is a misimplementation or is defined this way in the algorithm. Obviously this cannot be the expected behavior. The second tag should be interpreted as a tag. Nikita Popov
Re: [whatwg] Canvas size and double buffering.
I tried to solve the aliasing problem in Firefox and found out, that it really isn't possible to get it right, if you set the width and height in CSS: If you leave the css-width/height as it is when resizing the canvas, it will get blurred in Firefox. If you change it to 'auto' it won't resize correctly next time. So the only possibility is to get sharp lines and correct sizing is to first set the css-width/height procentually in JavaScript, then set the canvas.width/height using getBoundingClientRect and than setting css-width/height to 'auto'. (Everything on every resize). Furthermore you have to add one Pixel to the width if it isn't dividable by 2, because Chrome would add a strange white line otherwise. So here is how it looks: http://nikic.lima-city.de/canvastest2.html Works in Firefox and Google Chrome. Sorry for double post.
Re: [whatwg] Canvas size and double buffering.
Am 04.02.2010 01:00, schrieb Tim Hutt: On 3 February 2010 23:16, Boris Zbarsky wrote: On 2/3/10 6:12 PM, Tim Hutt wrote: Ah yes that works nicely Hmm maybe I spoke too soon. The interaction of the CSS size and the canvas.width/height is confounding! It seems if you set a CSS width of, say 80% then that is that and you are stuck with it. Unfortunately it doesn't round to the nearest pixel! I have created a test case here: http://concentriclivers.com/canvas.html (the source is nicely formatted and very short) If anyone can get it to work as described on that page, then thank you! Otherwise I think things need to be changed to make it possible. http://nikic.lima-city.de/canvastest.html This one satisfies at least the styling conditions (in Firefox and Chrome): * The canvas has 80% width * The canvas has 50% height (This one worked in Firefox only after setting height 100% on body and html. Strange...) * Resizes when the browser resizes * Is centered I only couldn't figure out the "Always draw a non-aliased pattern of lines" part in Firefox. I tried some stuff, but it didn't work.
[whatwg] Output of web applications
I think everyone who uses PHP, JavaScript, a.s.o. knows, that at some
point the user makes something wrong and you want to throw an error
("Your email's not valid (MX-Record not set.)") or an information ("You
have logged in successfully.").
Know I do this using or analogically.
As errors or other direct responses to user interaction are not the same
as some different text, I think there should be a possibility to mark
them up appropriately.
I first searched in the Spec for some existing elements for output, but
only found which is for sample output only.
I don't quite know which element name to use best, maybe:
/
/
(The question is, what is , error or info?)
What do you think?
Re: [whatwg] <* caption>
The original idea for using the attribute was that it could apply to a wide range of elements, like p, div, etc. But that makes it difficult for browsers to provide sensible default styling for captions, since it requires carefully overriding existing defaults for so many other elements. To some extent, it even makes it difficult for authors to provide reasonable styles if they can't guarantee which elements content writers will choose for their caption. Imagine designing a CMS template with some default styles for figure and caption, the CSS in the template would have to deal with so many possible element choices just for the caption, it'll be difficult to get it right and test everything. This does make sense. Would be really hard, for sure. There are only 2 sensible options for element choices: or introducing a new element. Using dt/dd is *not* and was never a sensible choice for figure, and the idea must be dropped. As caption and legend have much too many backwards compatibility issues, the only possible solution is either a new element or dropping the whole figure-thing. The second thing should really be taken into account. Better no syntax than bad syntax :) What tag-titles could be used to mark the captions up? I thought of or (first is better). Does not seem to be taken, but I don't know whether it is as intuitive. (But I as a German, who can't speak English very well, would search for "html5 image description" next after "html5 caption".) MfG Nikita Popov
Re: [whatwg] <* caption>
Yeah, I think this dd, dt thing isn't really intuitive. (Looks like
these two elements from definition lists are now used everywhere.)
Your proposed syntax looks more nice. But still, why do we need the
figure-wrapper? It would be cleaner syntax, in my eyes, if you could
easily specify an element that is related as a caption to another
element. Could look like this:
The Cutest Animal
or
The Cutest Animal
Or used in the code-context:
echo 0;
that is expresses very well the relation between content and caption.
Furthermore, any related content could be marked up this way. For
example, there is this strange hgoup-tag, that's used fore grouping
title and subtitle:
Somethind great happened
Now some subtitle in a newspaper article...
If I wanted to place an image between title and subtitle of the article,
it would look something like this:
Somethind great happened
Descr. of img.
Now some subtitle in a newspaper article...
The img doesn't really belong in the hgroup. Using the for-attr it would
look like this:
Something great happened
Descr. of img.
Now some subtitle in a newspaper
article...
Here styling is the problem: The fors are all identical and can't be
distinguished. So maybe get the caption-attr. back in?
Something great happened
Descr. of img.
Now some subtitle in a
newspaper article...
Which would be not so nice looking in XML ('caption="caption"').
So maybe combine them (which would, too, solve the problem of usage of
"for" for forms. [Nice three fors...]]):
Something great happened
Descr. of img.
Now some subtitle in a
newspaper article...
Philip Jägenstedt schrieb:
As currently speced, the proper usage of is:
The Cutest Animal
Apart from all that has been said about legacy parsing, leaking style
in IE, etc I would (perhaps not be the first to) add:
1. It seems quite easy to confuse or mistype dd/dt. Without guessing
how often authors will get it wrong, I think everyone agrees that (all
else equal) a syntax which is harder to confuse/mistype is better.
2. Only the caption needs to be marked up, the content is implicitly
everything else. While some content may need a wrapping element for
styling, e.g. usually does not.
3. Aesthetics. (My eyes are bleeding, but I can't speak for anyone
else's.)
The main difficulty with coming up with something better seems to have
been finding a name for an element which isn't already taken. If
that's the only issue, why not just take some inspiration from pubdate> and use an attribute instead?
The Cutest Animal
At least to me, it looks clean enough and there are no serious parsing
issues (just use document.createElement("figure") for IE).
The caption is easy to style with "figure *[caption]" or any number of
easy workarounds for browsers that don't support CSS attribute
selectors (IE6?).
I haven't been following the discussions on closely, so if
this has already been discussed and rejected please link me in the
right direction.
Re: [whatwg] [HTML5] A content in elements for ASCII art
I think the idea of replacing the alt-attribute by the content of img is very good. An image used as an needs to be content-related an therefore you often could place a descriptive text into it. This would lead us to img being only a normal HTML-element with normal content, but the ability of specifying an image by "src". On the problem of implementation: Test Hallo World If the browser knows the syntax, it'll render correct, if not it'll render correct only in case broken_url.jpg is really broken. Otherwise the text would be underneath it. So you would need to position the span over the img. I don't know whether it's worth the effort, but it would be a better syntax than alt, in my eyes. Nikita Popov
Re: [whatwg] Proposal: Extension to the base element
Fabian Freiburg schrieb: PROPOSAL The "base" element is very helpful. Trouble is that it affects all relative links and "src" attributes. Especially for the "src" attributes it would be very useful if it could define a context or media type to which it belongs. With this it would be possible to define a "base" URI fore. g. images, javascripts or stylesheets. Furthermore it would be very easy to use a CDN for serving static media files. There are probably some more advantages. I don't really understand why or when you need this addition. I personally use only if I rewrite the URI to some sub-directory stuff. (index.php?page=download&action=view&name=foobar gets /download/view:foobar) Or do you want to use it to specify, that all images can be found in upload/images/? MfG Nikita Popov
Re: [whatwg] WebStandrd for theme
narendra sisodiya schrieb:
Many blogging site like posterous has theme editor for their
blog/website. It is a xml file looks more like html. Following file
was a long file which I have edited and deleted the unnecessary
content. I think this is a non-standard way to design theme. Do we
have any standard to such requirement ? OR we do not need any standard
at all for such requirement.
PS: I have searched on FBML too. Google says, It is a propri. standard
of facebook.
In the document you provided I couldn't find any tag using the
fb-namespace. All the other things, like {something}, are a typical
method to mark up things to be inserted in Templates. They are processed
by a templating engine. And I really do think that things like this
don't belong to HTML, they are many templating systems, many PHP
developers have their own (as I do) using markup that's convenient for them.
Nikita Popov
Re: [whatwg] rp is a styling tag and has no semantic function
Futomi Hatano schrieb:
> On Fri, 30 Oct 2009 15:00:10 +0100
> Nikita Popov wrote:
>
>
>> I am not sure whether it is as easy. Please consider this one:
>>
>> char pron 1
>> another char pron 2 pron 3
>> and some other text without a ruby annotation.
>>
>> If a screen-reader now only would read the ruby-annotations, it would
>> sound like this: "pron 1 pron 2 pron 3" and the rest of the text
>> wouldn't be read.
>>
>
> The text without a ruby annotation should not be in .
> It should be marked up like this:
>
>
> char pron 1
> another char pron 2 pron 3
>
> and some other text without a ruby annotation.
>
Yes, that's right. But there are always people not as strict. I think
some ninety-nine percent of websites aren't valid an even less semantic.
HTML5 mustn't be planed only for the exemplary developers but for the
standard-user, too.
>> is much better. But I still think that
>>
>> 漢字(かんじ)
>>
>> is not the right way to mark this up. Much better would be:
>>
>> 漢字かんじ
>>
>
> If all browsers support like IE, I think so.
> Then, the CSS that you mentioned blow would be not necessary.
>
Yes, that would be perfect. But for now that's not how it is.
> Now, we are talking about non-IE borwsers which don't support ,
> For such browses, we have to show "(" and ")" in a phrase for a ruby
> annotations.
> If "(" and ")" appear in a phrase, these are part of the phrase semantically.
> So, I think that "(" and ")" should be marked up in HTML.
>
>
>> An these two CSS-definitions:
>> rt:after {
>> content: ')';
>> }
>> rt:before {
>> content: '(';
>> }
>> This would add '(' before and ')' after all ruby-annotations. The only
>> problem is: Browsers being able to render ruby, will render the
>> parentheses too. So there must be another CSS-property, something like:
>> rt:after {
>> content: ')';
>> display: ruby-parenthese;
>> }
>> rt:before {
>> content: '(';
>> display: ruby-parenthese;
>> }
>> Browsers not knowing this value for ruby will fall back to display:
>> inline; and so display the parenthese. Browsers knowing ruby and this
>> property would not show the parentheses.
>> I think this is a much cleaner solution for the parentheses and the code
>> gets more readable.
>>
>
> It is a solution presentationally, but it is not a solution semantically, I
> think.
> Your solution is useless for UAs which don't support CSS, because parentheses
> would not be displayed.
>
Screen-readers are yet another problem: I'm not sure, what's better:
"ka-n-ka-n-ji-ji" or
"ka-n-bracketopen-ka-n-bracketclose-ji-bracketopen-ji-bracketclose". I
think the first one is even better, because the text is only duplicated
and the reader mustn't read the brackets, too. (This is for
screen-readers not supporting ruby. The ones that support it can then
handle it by only reading out the rt, as you proposed. [Though you need
to consider the problem above.])
So, what do we get using the CSS and this markup:
char pron
Browser, no ruby implementation: char (pron)
Browser, ruby implementation: correct rendering of ruby, without brackets.
Screen-reader, no ruby: char pron
Screen-reader, ruby: pron (If using your proposition)
Using the rp-tag using this markup:
char (pron)
Browser, no ruby implementation: char (pron)
Browser, ruby implementation: correct rendering of ruby, without brackets.
Screen-reader, no ruby: char bracketopen pron bracketclose
Screen-reader, ruby: pron (If using your proposition)
Both variants are the same, only differing in the point "screen-reader,
no ruby". (And this is discussed above.)
> Parentheses for a ruby is not for decoration.
> It is a part of phrase.
> Please consider this phrase:
>
> This interest was borne from the realization that XML's deployment as a
> Web technology was limited to entirely new technologies (like RSS and later
> Atom), rather than as a replacement for existing deployed technologies (like
> HTML).
>
> Do you use CSS for "(like RSS and later Atom)" or "(like HTML)" ?
> I hope that you say no.
> I think that parentheses for a ruby is same as this case.
>
No, I do think it is an absolutely different situation. In the above
example the parentheses are part of the content. If it is convenient in
the English language to use parentheses to mark examples, then they are
part of the language and so of the content.
With ruby, it's something different. If they would really belong to the
content, why should you make them invisible? In my eyes they are only
used to indicate the reader, that the text between them isn't really at
the right place. This could be also done by giving them a color: grey;.
The parentheses are only one of many *stylistical* variants to show that
the characters are a ruby not being able to be displayed. And so, for
me, it's a problem of CSS.
Nikita Popov
Re: [whatwg] rp is a styling tag and has no semantic function
Futomi Hatano schrieb:
> On Fri, 30 Oct 2009 11:10:59 +0100
> Nikita Popov wrote:
>
>> Talking about screen-readers: How should a screen-reader actually handle
>> ruby annotations? In this case
>>
>> 漢 かん
>> 字 じ
>>
>> it would be quite strange if a screen-reader read the annotations,
>> because they have the same content as the ruby base text. (I hope this
>> is correct. I don't know the Japanese language, but I understood it as
>> 漢 beeing same as かん only in a different "way" of writing.) So the
>> reader must not read the annotation.
>>
>
> More correctly, screen-readers should read only the contents of rather
> than the base text.
> That is, screen-readers are expected to read it as "ka-n-ji" from s.
> Of course, screen-readers which don't support repeat 2 times such like
> "ka-n-ka-n-ji-ji" as you know.
>
I am not sure whether it is as easy. Please consider this one:
char pron 1
another char pron 2 pron 3
and some other text without a ruby annotation.
If a screen-reader now only would read the ruby-annotations, it would
sound like this: "pron 1 pron 2 pron 3" and the rest of the text
wouldn't be read.
> We also have to get easy to read for visual browser users.
> But, the markup above is rendered by non-IE browsers as below.
>
> 漢かん字じ
>
> We feel it is odd.
> So, I want to mark it up like this.
>
> 漢字(かんじ)
>
> This markup is rendered by non-IE browsers as below.
>
> 漢字(かんじ)
>
> It's natural and easy to understand.
>
I fully agree that
漢かん字じ
is odd and not really understandable and that
漢字(かんじ)
is much better. But I still think that
漢字(かんじ)
is not the right way to mark this up. Much better would be:
漢字かんじ
An these two CSS-definitions:
rt:after {
content: ')';
}
rt:before {
content: '(';
}
This would add '(' before and ')' after all ruby-annotations. The only
problem is: Browsers being able to render ruby, will render the
parentheses too. So there must be another CSS-property, something like:
rt:after {
content: ')';
display: ruby-parenthese;
}
rt:before {
content: '(';
display: ruby-parenthese;
}
Browsers not knowing this value for ruby will fall back to display:
inline; and so display the parenthese. Browsers knowing ruby and this
property would not show the parentheses.
I think this is a much cleaner solution for the parentheses and the code
gets more readable.
Nikita Popov
Re: [whatwg] rp is a styling tag and has no semantic function
Futomi Hatano schrieb: > If ATs(e.g. screen reader) know the rp element, it can remove the content of > the rp element. > So, we can get only true annotations from ATs, without parentheses. > I don't want hear parentheses from a screen reader. > > I hope that all browsers (including ATs) support the ruby element. > If so, I think the rp element is not necessary. > > Thank you. > > -- > Futomi Hatano > www.html5.jp > > I think this element is necessary in the HTML5 spec. Talking about screen-readers: How should a screen-reader actually handle ruby annotations? In this case 漢 かん 字 じ it would be quite strange if a screen-reader read the annotations, because they have the same content as the ruby base text. (I hope this is correct. I don't know the Japanese language, but I understood it as 漢 beeing same as かん only in a different "way" of writing.) So the reader must not read the annotation. In an example i got from an older W3C spec, it's different: 10 31 2002 Month Day Year Expiration Date As this markup isn't used anymore with HTML5, here's how it would be (dropping the "expiration date"): 10 Month 31 Day 2002 Year This one now should be read out by the screen-reader. Otherwise the meaning of the numbers may be not as clear. (Or is the date-example out-of-date and ruby shouldn't be used there?)
[whatwg] rp is a styling tag and has no semantic function
In the spec the use of the rp-tag is shown like this: 漢 (かん) 字 (じ) What semantic function has the rp-tag? No. It is only styling for browsers not supporting ruby-text. So I think this element musn't be in the HTML5 spec. You can add the brackets before and after the ruby text using CSS pseudoclasses (:after, :before).
