Re: [whatwg] Features for responsive Web design
While it's unlikely that screen resolution will go above 2x in the near future, should we be taking into account the zooming of specific elements that might result in the need for larger artwork? (take icons, that can scale all the way up to 512px or above) On 13/08/2012, at 5:39 PM, Henri Sivonen hsivo...@iki.fi wrote: Another thing worth considering is if ever anyone is really going to go over 2x, given that at normal viewing distances 2x is roughly enough to saturate the resolution of the human eye (hence the retina branding). Even for printing photos, 192 pixels per inch should result in very good quality, and for line art, authors should use SVG instead of bitmaps anyway.
Re: [whatwg] 'Main Part of the Content' Idiom
The purpose of all the new tags, is so the machine can figure out what is NOT main content, and assume everything else is. With proper use of sectioning and aside as well as header and footers this can be mostly achieved today. On 4/06/2010, at 5:39 PM, Daniel Persson wrote: I am not advocating ad-tags. The idea of globally structuring content on the web is very appealing, it would make it easier for a lot of things and a lot of people. Let's do it! ...but I can't see it happening where body would be main content + ads + anything there is not a sensible tag for + anything a lazy/stressed/unconscious author didn't tag otherwise. Let's just have a main content tag or a strong main content strategy. Thanks /Daniel On Fri, Jun 4, 2010 at 6:07 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 18:03 +0200, Daniel Persson wrote: Some websites are very crowded. I have no particular example. Blogs and easily accessible CMS's, people trying to make a buck from excessive advertising on their site, people cramming a lot of info/screen unit. Companies too, old media: http://www.aftonbladet.se/ (major Swedish paper, watch your eyes) . body will hold a lot of stuff that is not main content, other content will spill over into body (unless there is a conscious author, and vast use of aside). It should be easy for authors to define main content. It s a pedagogical issue, where authors not too concerned with standards compliance, should have an easy escape of at least defining the most important on the site. Thanks /Daniel On Fri, Jun 4, 2010 at 5:10 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 17:05 +0200, Daniel Persson wrote: If i view the html-web as it is now, inside body there are so much irrelevant content (where else to put it?). In order for body to be the main content, there has to be tags for everything else. This will be very hard for authors to implement (I am talking real world, amateur, do-it-yourself, stressed professionals). It is IMHO very beautiful code-wise, and organisationally, to state that everything in body is main content, but it will not benefit a structurally marked-up web. Thanks /Daniel On Fri, Jun 4, 2010 at 4:37 PM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Fri, 2010-06-04 at 16:27 +0200, Daniel Persson wrote: I am the one posting the question on the help list. To me, the lack of html5 definition of main content, ie body copy in paper publishing, is a big mistake. Imagine the amount of sites where everything else includes a lot of unimportant extra, or peripheral, content. Content which is not necessarily hierarchically legible by a machine. Getting authors to be disciplined about defining main content is more important than being disciplined about nav, footer, header, section etc, in order not to negate the meaning of html5 structural mark-up. Suggestion bodycopy... or, preferred, bread. /Daniel On Fri, Jun 4, 2010 at 1:55 PM, Smylers smyl...@stripey.com wrote: The HTML5 spec should define how to mark up the main content on a page (even if the answer is by omission). This is something that many authors ask about, the latest example being today's thread on the help mailing list: http://lists.whatwg.org/htdig.cgi/help-whatwg.org/2010-June/000561.html Please could this be added to the 'idioms' section, perhaps giving examples of when article or section might be appropriate as well as one in which the main content is simply that which isn't in header, aside, etc. Thanks. Smylers -- http://twitter.com/Smylers2 It's my understanding that everything within the body tag is considered body content, and the new header and footer tags, etc, are just there to give more meaning about the type of body content. Thanks, Ash http://www.ashleysheridan.co.uk The fact that there is so much irrelevant content inside the body tag is because some people consider that body content. Do you have a more specific example of this? Thanks, Ash http://www.ashleysheridan.co.uk I believe there was a proposal for an advert tag purely for adverts (I don't remember where I heard it) but it wasn't a realistic idea. If we could easily identify content we didn't want to see, and could strip it out before it even got to our browser, what incentive would people have to use it if the adverts are their only source of revenue? As such, it's not very feasible to distinguish between different types of content, and even if there were tags, a lot of people wouldn't use them because it would have a negative impact. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] RFC: input type=username
On 5/05/2010, at 9:09 PM, Christoph Päper wrote: Eitan Adler: A type=username is added to the input element. type=username would MUST only be used for the name that is used to log in to the site. It MUST NOT be used for registration forms or anything else that requires a username. A form MAY have up to one (but not more) type=username input field. I agree with whomever mentioned that form role=login seems more appropriate. Anyhow, I wondered whether it makes sense to apply microformats to such forms, perhaps reusing ‘hcard’: form class=vcard role=login method=post action=./ input type=text name=username class=nickname input type=password name=password input type=submit /form Nick and user name are probably not the same all that often and differ by site, so this probably doesn’t make sense at all. Still, form field semantics (‘name’/‘id’ and ‘class’ or ‘role’) may improve through some kind of standardization, although names shouldn’t be as clumsy as in RFC 3106 (ECML: Field Specifications for E-Commerce) when applied to HTML forms. form action=http://ecom.example.com; method=post class=Ecom fieldset class=Payment-Card legendPlease enter card information/legend label class=NameYour name on the card input type=text name=Ecom_Payment_Card_Name size=40 /label label class=NumberThe card number input type=text name=Ecom_Payment_Card_Number size=19 /label label class=ExpDateExpiration date (MM YY) input type=month class=Month name=Ecom_Payment_Card_ExpDate_Month size=2 input type=year class=Year name=Ecom_Payment_Card_ExpDate_Year size=4 /label input type=hidden class=Protocol name=Ecom_Payment_Card_Protocol /fieldset input type=hidden class=SchemaVersion name=Ecom_SchemaVersion value=http://www.ecml.org/version/1.1; input type=submit input type=reset /form I don't know if it's relevant, but if we're thinking backwards compatibility, keep in mind earlier versions of ASP.NET only allow one form per page, so wrapping a login in a form tag isn't really an option. Someone tell me if I'm wrong on that though, I'm just a designer :) -- Steve Dennis www.subcide.com
Re: [whatwg] RFC: input type=username
On 4/05/2010, at 9:07 AM, timeless wrote: On Tue, May 4, 2010 at 10:08 AM, Eitan Adler eitanadlerl...@gmail.com wrote: 3) Currently autofill for usernames looks for something like id=username or name=username. However on certain websites this fails. Why would a site which doesn't cooperate with today's autofill features choose to cooperate with your proposal? sites typically are either stupid or evil, and neither are likely to embrace new standards. Because id=username isn't a standard as such. Having it specified in a spec is likely to help people adopt it more quickly. Saying why bother? about all the broken sites on the web totally defeats the purpose of what everyone here's trying to achieve. -- Steve Dennis www.subcide.com
Re: [whatwg] img as a layout tool to describe the displayed region of a CSS background-image
On 28/04/2010, at 7:43 PM, Tab Atkins Jr. wrote: On Wed, Apr 28, 2010 at 4:31 AM, Ingo Chao i4c...@googlemail.com wrote: http://dev.w3.org/html5/spec/Overview.html#the-img-element The img must not be used as a layout tool. I think this may be a little vague/broad. I understand the intention, but say for example I have a logo image in the top left of my header, and my header doesn't have a static height set (in case something in the header needs it to grow or shrink for instance), then the height of the logo image is dictating the height of its parent, and this would seem to me, to be using an img as a layout tool, in a sense. In particular, img elements should not be used to display transparent images, as they rarely convey meaning and rarely add anything useful to the document. An img with a given transparent image for src cuts an area of a sprite. ( = img as a layout tool to describe the displayed region of a CSS background-image.) Is this usage of the img element considered invalid (non-conforming)? Sprites for icons, while widely used and considered fairly good practice, still seem pretty hack-ish to me. Icons can (arguably) help convey meaning in a document, and changing a background position to change that meaning doesn't seem like the best way of achieving this. I am of course thinking like 10 years into the future here, as sprites are perfectly fine for lots of uses today, but as concurrent connections become less of a problem, I think lots of us will look back on sprites the same way we see spacer.gifs, which were a necessary evil at the time. - Steve Dennis Yes, this is using the img as a layout tool. Specifically, you're using the img to avoid specifying width and height in CSS, and to enable further layout hacks with sprites using background-positioning. ~TJ
