[whatwg] The semantics of visual offsetting vs. verbal offsetting

[brenton strine]

My understanding of the semantics of  and  vs.  and  is
that the former indicate a stress, emphasis, offset or importance that
would be expressed verbally, if reading aloud.

On the other hand, the  and  tags indicate stress, emphasis, offset
or importance that is visual or typographic.

I frequently see people arguing that  is the most semantic element
to use for a term or keyword because it is the most "important," but in a
situation where you would never change the way you read the sentence
verbally, but rather, just want the typographic indication that it's a
term. To me, I think this is coming from some ambiguity in the word
"important" that causes people to fundamentally misunderstand when to use
 vs .

Is my understanding (i.e., thinking in terms of visual vs. verbal offset as
a way of clarifying the meaning of the definitions) right here, and if so,
is there some sort of less ambiguous, authoritative document that I can
point people to when these discussions come up? Semantics conversations
always seem to come back to a fundamental disagreement about the meaning of
the words used in the W3C specification.

[whatwg] What's the element for a paragraph label?

[brenton strine]

For example:


  Tip: You should always use the most semantic element!


Oops,  is for inputs, so that's not right! Should I use a 
heading? Doesn't seem right either. Is this a case for ? The
specification doesn't mention labels under the  definition.

Is there a semantic element that can be used in a situation like this? If
so, I propose adding "label" to the specification for that element.

Then again, maybe this most appropriately a .

Cheers!

[whatwg] Controlling the UI on input type=date

[brenton strine]

It is currently difficult to control the visibility of the UI (e.g. little
arrows, spinners, etc) on new input types like datetime, number, range,
color, etc.

It seems that many developers want to use the semantic attributes, but need
to be able to hide the little arrows for various reasons, and so they are
sticking with type=text (e.g. http://stackoverflow.com/q/11418289/925897

).

Reasons developers might want to control the visibility of the UI:
- developer has built their own datepicker/numberfinder/colorpicker/etc
- developer wants to display just the values (as if it were type=text) upon
printing, or when readonly, or when not active

As browsers add support, there will likely be ways to control this using
vendor-specific CSS, but not only will this vary from browser to browser,
it will vary among the different input types. For example, in Chrome it is
currently possible to hide the slider arrows on the number input:

input[type=number]::-webkit-inner-spin-button{
-webkit-appearance: none;
}

This kind of code is clearly going to be very difficult to maintain and
keep up to date. I don't think a CSS solution is going to work. Has there
been discussion here on an input attribute that controls the UI? Perhaps
something like this:

input type=date ui=false

Re: [whatwg] Correcting some misconceptions about Responsive Images

[brenton strine]

On Wed, May 16, 2012 at 12:13 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 I've been doing a lot of work today correcting misconceptions about
 the Responsive Images proposal that Hixie put into the spec today.  I
 was pretty astonished at how much misinformation was flying around;
 what's worse, this sort of misinformation was actually making people
 *angry*, which doesn't exactly make people willing to calmly listen to
 corrections.  So, hopefully this email finds everyone in calmer moods,
 so we can get everyone on the same page.

 Any others that people can think of?

I have a question regarding Tim Kadlec's summary of the order of
events in all of this [1]:

 1. Developers got involved in trying to standardize a solution to a
 common and important problem.
 2. The WHATWG told them to move the discussion to a community
 group.
 3. The discussion was moved (back in February), a general consenus
 (not unanimous, but a majority) was reached about the picture element.
 4. Another (partial) solution was proposed directly on the WHATWG
 list by an Apple employee.
 5. A discussion ensued regarding the two methods, where they
 overlapped, and how the general opinions of each. The majority of
 developers favored the picture element and the majority of implementors
 favored the srcset attribute.
 6. While the discussion was still taking place, and only 5 days after it
 was originally proposed, the srcset attribute (but not the picture element)
 was added to the draft.

His account has been quoted [2] elsewhere, and while Tim's order of
events seems mostly accurate, Jeremy Keith has clarified [3] that the
WHATWG never suggested a CG be created and that Ted's 'srcset'
solution wasn't as completely out of the blue as it seemed.

However, it still looks like the most upsetting implication of his
timeline, namely that the WHATWG is prioritizing implementors over
authors, remains unclarified. Is it a misconception to say that the
levels of priority outlined in the W3C HTML design principles [4] are
not being followed here? Especially since it seems that we can extend
Tim's timeline with:

7. Authors react negatively to the addition of 'srcset' in the draft.
8. The 'living' draft is not changed and the authors' anger eventually
fades into hopeless acceptance because once something goes in to the
draft, it is set in stone forever and for all time.

Ok, so 8 is both hyperbolic and in the future, but a lot of people
seem to think that this is where we are headed. Personally, I'm not
angry about this and I'm willing to calmly listen to corrections, I'm
just trying to wade through all the misinformation here.

-Brenton Strine

[1] http://timkadlec.com/2012/05/wtfwg/
[2] http://adactio.com/journal/5474/
[3] http://www.goodreads.com/author_blog_posts/2463167-secret-src
[4] http://www.w3.org/TR/html-design-principles/

[whatwg] Why isn't the pattern attribute applied to input type=number?

[brenton strine]

Regarding the an input with type in the number state, the spec states
that the pattern attribute must not be specified and do[es] not
applyhttp://dev.w3.org/html5/spec/common-input-element-attributes.html#do-not-apply
to
the element. (
http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#number-state-type-number
)

Why is it specifically blocked? Doesn't that encourage the use of a less
semantic text input type for numbers that need to be validated beyond
simple max and min?

What if you want the number to be either 13 or 16 digits long, as with a
credit card

pattern=(\d{5}([\-]\d{4})?)

or you want a US ZIP or ZP4 code which can either be n or n-

pattern=(\d{5}([\-]\d{4})?)

To get the pattern to validate, I have to (non-semantically) change the
input to the text state? I much prefer the current behavior of Firefox
(tested 9 and 10) which does validate the pattern.

Brenton Strine

Re: [whatwg] required attribute in label

[Brenton Strine]

 label class=required

and

 input id=name1 type=text requiredspannbsp;/span

are effective, but then again this would be too:

.../label*

It just seems a shame that we have this neat attribute that indicates
required controls, but we can't actually use it to change the
presentation adding additional code.

Brenton

[whatwg] HTML 5 will be ready in 2022

[Brenton Strine]

I know many web developers who get upset when they hear that HTML 5 is expected 
to become an official reccomendation in 2022.

But as we all know, HTML 5 is already having real world effects and even being 
implemented in browsers.

Is there some place that documents the parts of HTML 5 that are already up and 
running? Can I use canvas or video? In which browsers? What other tags can 
I use? What other fancy HTML 5 stuff can I do today in 2008? Shouldn't the 
whatwg wiki document that kind of stuff?

Brenton Strine

[whatwg] meta http-equiv=X-UA-Compatible content=IE=edge /

[Brenton Strine]

By now, everyone has heard that IE8 'passes' the Acid2
test, but (To paraphrase Jeremy Keith:
http://adactio.com/journal/1402/) won't render pages with
the new standards-compatibility unless you explicitly
tell it to with this meta tag:

meta http-equiv=X-UA-Compatible content=IE=edge /

--i.e. it actually won't pass Acid2 because the test
doesn't have that meta tag in it. I agree with Jeremy
that this is a mistake. One of the reasons I write
standards-compatible code is so that my websites will
work in future browsers when they support new/better
features. All such webpages are effectively locked into
IE7 now, and won't get any benefits of the newer browsers
unless I add this new meta tag. 

The example from the article is generated content. Since
IE8 isn't out the door yet, I wonder if we can't do
anything about this to prevent a bad situation for years
to come. 

My thought is this (and I'm hoping other people will come
up with better ideas). Give HTML the ability to declare
specific technologies that it uses, such that if a
browser supports that technology, it makes use of it.
Sort of like using object detection in javascript instead
of messing with the user agent string. For example,
assume an amazing new image format comes out called
AwesomeImg--Opera 11 supports it, but you're not sure
when IE will. Maybe IE10. But you don't want to lock your
site into IE10 mode because it might break in IE10, or
IE10 might still not support all your features but IE11
would have.

There should be a way to tell the browser it can
implement your technology without locking your website
into a specific version. A website can then avoid the use
of the edge attribute, which might cause future
breakage, but also would avoid being locked eternally in
the limitations of a specific browser version, be it IE7,
IE8, IE9, etc.

If we get this into the spec soon enough, Microsoft might
incorporate it in IE8 before it releases. What do you
think? Whether it's a good idea or a bad idea, I feel
that the whatwg needs to address this issue somehow.

Brenton Strine

[whatwg] additional empty elements

[Brenton Strine]

I would like to know what other people think about
creating more empty elements in HTML5.

Say, for example, you have a website which has sections
of content that are indented variously. It would be easy
to accomplish the different styles using classes:

div class=firstgroupThis text isn't indented at
all!/div
div class=secondgroupThis text is indented a
little./div
div class=thirdgroupLots of
indentation./div
div class=firstgroupNo indentation here!/div

However, if I then wanted to add additional special
styling to the first and third div, (e.g.. a border and
background color) it is less graceful. I could add style
attributes, but that would be wasteful if I want to do
this on a large scale. Multiple classes would be
confusing. 

A nice solution would be the addition of a few div tags.
(e.g. div2, div3, div4 and div5.) Then you could
do something like this:

style
div1 {text-indent:0px;}
div2 {text-indent:10px;}
div3 {text-indent:20px;}
/style

Then:

div1This text isn't indented at all!/div1
div2This text is indented a little./div2
div3Lots of indentation./div3
div1No indentation here!/div1

This is much more human-readable, and the addition of
additional styles is now elegant and easy with the use of
classes.

div1 class=bluestyleThis text isn't indented at
all!/div1
div2This text is indented a little./div2
div3 class=redstyleLots of
indentation./div3
div1No indentation here!/div1

 I also think that it would simply be easier to write
code if there were a few extra non-semantic empty tags.
HTML5 needs improvements that will make people want to
use it. Making it easier to code than HTML 4 will ensure
a quicker and wider acceptance.

I am okay with the unimaginative numbering of the extra
elements, as it would make it easy to have a lot of new
elements. However, there are countless possibilities:
section, chunk, partition, block, enclosure,
zone, figure, sector, quadrant etc...

Are there other people who have found themselves wishing
for another span or div-like tag?


Brenton Strine

Re: [whatwg] additional empty elements

[Brenton Strine]

 HTML is a language for markup meaningful by itself, not
just as a hook for CSS. 
 div2doesn't mean anything.

That doesn't seem very practical to me. If all HTML tags
imply some meaning, then you are advocating the
elimination of presentation, not it's separation. If
there weren't any CSS hooks, wouldn't people just
(incorrectly) use other tags, like h1? I think that CSS
and HTML are unbreakably connected. 

Brenton

[whatwg] Suggestion for new element/attribute

[Brenton Strine]

Hello,

I am new here, so please let me know if I am doing
anything out of order.

I would like to make a suggestion for soemthing I want to
see in HTML5.

I call it the inflate tag. inflate.

The purpose of this tag is to expand that which contains
it as if it were full of text. I have seen many websites
where the designers were forced to put long strings of
hidden text into a cell in order to make it expand
correctly. Thus text browsers find strange segments like
this:

w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w w w w w w w w 

Of course, developers already have the ability to specify
the width in terms of pixels, ems, percent, and tons of
other stuff. But there are times, particularly in fluid
design, when you can't get the div to work the way you
want without text to expand it.

This could even be an attribute rather than a tag:
width=inflate.

Brenton

Re: [whatwg] Suggestion for new element/attribute

[Brenton Strine]

Consider this case:

You have a table one row high with two cells. It's width
is 100%.

You want the width of the left cell to be only as big as
the content, and you want the right cell to take up all
the rest of the space.

However, the amount of content in both the right and the
left cell changes, so you can't give a percent or a pixel
width. 

In that situation, you could either 1) intentionally give
the right cell an incorrect width of 100%, or 2) put a
whole lot of invisible text in it, so that the cell
always expands enough to make the left cell only the
minimum size needed.

-Original Message-
From: Benjamin Hawkes-Lewis
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 25, 2007 3:44 PM
To: Brenton Strine
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Suggestion for new
element/attribute

This sounds very much like something that should be done
in CSS, not HTML. But can you explain what you mean by
expand ... as if it were full of text? If something is
already a given size, then filling it with text should
not make it expand.

--
Benjamin Hawkes-Lewis

Brenton Strine wrote:
 Hello,
 
 I am new here, so please let me know if I am doing
 anything out of order.
 
 I would like to make a suggestion for soemthing I want
to
 see in HTML5.
 
 I call it the inflate tag. inflate.
 
 The purpose of this tag is to expand that which
contains
 it as if it were full of text. I have seen many
websites
 where the designers were forced to put long strings of
 hidden text into a cell in order to make it expand
 correctly. Thus text browsers find strange segments
like
 this:
 
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w w w w w w w w w w w w w w w w w w w w w
w
 w w w w w w w w 
 
 Of course, developers already have the ability to
specify
 the width in terms of pixels, ems, percent, and tons of
 other stuff. But there are times, particularly in fluid
 design, when you can't get the div to work the way you
 want without text to expand it.
 
 This could even be an attribute rather than a tag:
 width=inflate.
 
 Brenton
 

Re: [whatwg] sarcasm

[Brenton Strine]

So why not use the q element for irony as well, since a quote already
indicates both quotations and irony.

On 4/24/07, Elliotte Harold [EMAIL PROTECTED] wrote:

Alexey Feldgendler wrote:

 In Western typography, there is already a tradition to mark up irony
 with quotation marks:

 Yeah, George W. Bush has been such a great president.

There's an even stronger tradition to mark quotes with quotation marks,
and yet we have the q element.




--
Elliotte Rusty Harold  [EMAIL PROTECTED]
Java I/O 2nd Edition Just Published!
http://www.cafeaulait.org/books/javaio2/
http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/