Re: [WSG] HTML5 offline storage question
Asking why not just use the cache is a valid question. In this case, using HTML5 storage to house files doesn't seem to be tapping into all HTML5 storage can do--but it's not violating what storage can do either (so far as I know). HTML5 storage is like cookies: "Simply put, it’s a way for web pages to store named key/value pairs locally, within the client web browser. Like cookies, this data persists even after you navigate away from the web site, close your browser tab, exit your browser, or what have you. Unlike cookies, this data is never transmitted to the remote web server (unless you go out of your way to send it manually)." That's from: http://diveintohtml5.org/storage.html#localstorage So, HTML5 storage is more for data storage--storing key/value pairs (like massive cookies)--than just a repository of files. This is how I understand it. Others may know more. I'd think a iPhone/iPad native app would want to look beyond HTML5 storage and into File Management. But if this is a web app, then HTML5 storage might be the only option. But I'm far from being an expert. -jody On Aug 9, 2010, at 12:59 AM, Josh Godsiff wrote: > I avoid Apple products like the plague, so perhaps I'm missing some info > here, but what's wrong with simply getting the user to download the file > in the normal fashion? > > - Josh > > On 9/8/2010 3:11 PM, Breton Slivka wrote: >> The iPhone has a 5mb upper limit per page. I think the ipad's limit is 10mb >> but I am not sure. So in other words, no. >> >> -Breton >> >> On 09/08/2010, at 2:55 PM, Andrew Harris wrote: >> >> >>> Hi all, I'm asking around the traps on a question which has come up at work. >>> >>> We want to develop an iPad app to will allow users to download from a >>> website (like a synch) large quantities (hundreds of MB) of documents >>> (pdf and word) for reading offline. >>> >>> Is the offline storage tool in HTML5 designed for this sort of heavy >>> lifting? >>> are there storage limitations? >>> on an iPad? >>> >>> I've found a few examples of the tool in action and read bits and >>> pieces, but it all seems to be about storing small chunks of data, not >>> humunguous great whumps of it. >>> >>> -- >>> Andrew Harris >>> and...@woowoowoo.com >>> http://www.woowoowoo.com >>> >>> ~~~<*>< ~~~ >>> >>> >>> *** >>> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >>> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >>> Help: memberh...@webstandardsgroup.org >>> *** >>> >>> >> >> *** >> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> Help: memberh...@webstandardsgroup.org >> *** >> >> > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > *** > *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] @media ordering in stylesheet
Thanks for the responses. I needed the experts in the group to confirm my suspicions. Best, jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] @media ordering in stylesheet
Hi all,
Does @media rule ordering in a stylesheet matter? For example, given the
following order:
@media print {
body {
#FF;
}
}
@media all {
body {
#99;
}
}
Will @media print override the @media all in this ordering?
Googling around, I've not found a clear answer to the question. So, any help is
appreciated.
Thanks in advance,
jody
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] EM bug in Safari 5?
If this helps: my MacBook Pro is about 2 months old and Safari's default is 16px. -jody On Jul 30, 2010, at 11:38 AM, tee wrote: > >>> >> >> I had this issue to then I checked safari's default font size and it >> was set to 12px instead of 16px like the other browsers. Once I >> changed that setting to 16px then they all looked the same. I would >> suggest verifying in your browsers that they all have the same px size >> set for their default font size before testing. > > Thanks for bringing this up. I changed it and now Safari renders the width > similar to others. > > This is very strange! The font size in my Safari is 14px. I'd just had this > computer about 6 months ago, and have no memory I altered the font size for > the reason I did in previous machine (mentioned in my previous email). > > Other browsers have default 16px. > > Do you have idea how Safari makes the calculation that resulted 121px > differences with 14px font size setting when width is set to 62em. > > tee > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > *** > > > *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] link rel="stylesheet" question
Many thanks to those who respond to the link rel="stylesheet" question, Best, jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] link rel="stylesheet" question
Hello all, In a stylesheet link, does the order of rel, href and type affect how a browser understands, loads, etc. a stylesheet? I usually see the rel attribute first, as in the example below, but does the order of attributes matter or is the order convention, convention meaning, "that's what most people do"? Thanks in advance, jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Overflow hidden and floated divs
I asked a similar question back in February and this link helped explain it:
http://www.quirksmode.org/css/clearing.html
-jody
On Jul 15, 2010, at 8:11 AM, Stevio wrote:
> I have a row of floated list items inside a container with height 1.2em,
> which is inside a parent div with a background colour.
>
> e.g. something like this (not the actual HTML of course ;) -
>
>
>
>
>
>
>
>
> If the floated list items were too wide, the rightmost list item jumped down
> beneath, but the container did not expand so it looked bad.
>
> However, if I add "overflow:hidden;" to the parent div, then the rightmost
> list item still jumps down, but now the box expands down the way, so it
> looks a lot better.
>
> My question is why does it do this? I have looked up what overflow hidden is
> meant to do and from what I read it sounds like the content should just get
> clipped at the right hand side and not be shown. Why is it causing the box
> to expand down the way?
>
> Thanks.
>
> Here is the CSS:
>
> #navigationbar {
> background-color:#DEDEDE;
> overflow:hidden;
> }
> #navigationbar ul {
> padding: 0.2em 0 0.2em 0;
> margin: 0px;
> list-style: none;
> height:1.2em;
> }
> #navigationbar ul li {
> padding: 0;
> margin: 0;
> display: block;
> float: left;
> }
>
>
>
> ***
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberh...@webstandardsgroup.org
> ***
>
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] the mysteries of overflow: hidden
Exactly. The magic confounds me. http://staff.washington.edu/jtate/overflow.html (I threw together the above example quickly. (Yes, embedded styles are a no-non, but it was easy to do in this situation.) Thanks a ton for the quirksmode link. It helps demystify the mystery. -jody On Feb 10, 2010, at 1:42 PM, akella wrote: > Apparently he is talking about overflow:hidden as a clearing floats fix. > (http://www.quirksmode.org/css/clearing.html) > Let me reformulate the question: why the property that serves for hiding smth > just make the wrapper stretch to accomodate containing floats. > As for me - i still consider this magic. May be W3C got smth on this topic. > > > Yuriy "akella" Artyukh, > http://cssing.org.ua > > > > On Wed, Feb 10, 2010 at 9:32 PM, Christian Snodgrass > wrote: > I'm not sure I understand what you're asking. Could you put together a quick > example to illustrate. > > Basically what overflow: hidden does is anything that doesn't fit into it's > given container is hidden, basically meaning that it doesn't affect the > height of it's container. This only works if the parent has a height set. If > it doesn't, overflow: hidden has absolutely no effect. > > Here is an example: http://www.arwebdesign.net/test2.html > > In the first one, the container has a static height (500px) and no overflow. > The text just streams right out of the container. > In the second one, the container still has a static height, but has overflow: > hidden. This time, the text just disappears. > In the third one, the container has no height set, but has overflow: hidden. > This time, the container's height stretches to accommodate it's contents. > In the fourth one, the container has no height set and has no overflow. This > functions exactly the same as the third. Overflow hidden had no effect on the > third one without a height being set. > > Hope that clarifies overflow: hidden a bit. > > - Christian > > > On 2/10/2010 1:50 PM, Jody Tate wrote: > (I'm a list lurker. Also, apologies if this has been covered before.) > > In CSS, setting a div to "overflow: hidden" solves a problem it shouldn't--at > least from the name of the property and value, it seems like it shouldn't. > > Often I'll have text, e.g. an h1, overflowing its containing/parent div, but > setting the containing/parent div to "overflow: hidden" causes the parent div > to set its height in a way that the formerly overflowing text no longer > overflows. > > I've seen this happen for years. Another developer showed me this fix years > ago. But over the years, I've never read an explanation why "overflow: > hidden" fixes a problem its name implies it wouldn't. > > Have others seen this? Any explanations? > > -jody > > > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > *** > > > > > > -- > Christian Snodgrass > CEO - Azure Ronin > http://www.arwebdesign.net > http://www.htmlblox.com > Phone: 859.816.7955 > > > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > *** > > > > *** > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: memberh...@webstandardsgroup.org > *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] the mysteries of overflow: hidden
(I'm a list lurker. Also, apologies if this has been covered before.) In CSS, setting a div to "overflow: hidden" solves a problem it shouldn't--at least from the name of the property and value, it seems like it shouldn't. Often I'll have text, e.g. an h1, overflowing its containing/parent div, but setting the containing/parent div to "overflow: hidden" causes the parent div to set its height in a way that the formerly overflowing text no longer overflows. I've seen this happen for years. Another developer showed me this fix years ago. But over the years, I've never read an explanation why "overflow: hidden" fixes a problem its name implies it wouldn't. Have others seen this? Any explanations? -jody *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Appropriate postings
I'm a lurker on the list, but primarily because the list, so far, has seemed like a place where people come for help solving specific, remedial problems with long-standing (in internet-time) solutions well-documented on the internet and in books. On 8/5/08 11:10 AM, "Rick Faircloth" <[EMAIL PROTECTED]> wrote: > And I would like to know what a list on any subject is for if not for helping > people understand the most basic principles and application of a give > practice. > A list on any topic must embrace all level of participants, beginners and > advanced, alike. If we think of the list as a classroom, a teaching environment, then it's standard practice to have separate beginning, advanced, etc. classes. At the university level, for example (in the US), classes at the 100 level tackle different issues than classes at the 200, 300 and 400 level. A list on a topic isn't required to embrace all levels of expertise. I've participated in many mailings lists where some requests for basic help were considered off-topic. Requests for help when answers can be found by via searches or reading books were often seen as inappropriate. I'd advocate (at the risk of sounding snobby), as some have suggested, for different lists--one to accommodate beginners and another to accommodate other developers interested, not in help with standards, but in the standards themselves. > Anyone who thinks a list about web standards should not first have as its > mission > to teach and clarify the basics of the tools of standardization, such as CSS, > is > mistaken. Unless expressly stated, a list must cater to the lowest common > denominator of its participants, not the highest. By doing so, those on the > bottom > are lifted up, instead of always being pushed down and kept in the dark. To think a list about web standards doesn't need to have teaching as its first mission is not mistaken, it's considering that a different goal or multiple goals might be acceptable. Web standards are not new, though they may be new to some list users. Teaching can be a function, but if helping others with the basics is its sole function, as it's becoming here, it neglects another portion of the list's members, those who have been using web standards since their inception and hope to have extended discussions about, for example, XHTML vs. HTML5, CSS3, current and upcoming browser implementation of standards, emerging standards and so on. -jody -- Jody Tate http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Marking Up Poems
I'd stress what Jon Tan wrote: "My recommendation would be for stanzas and line breaks for most verse." Stanzas are usually taught as the paragraph of poetry and verses are referred to as line breaks. Side note you're free to ignore: I'd argue most of the historical bits below are incorrect in the details, but are correct in general. Jonson's _English Grammar_ is a great snapshot of the period's grammar eccentricities, but hardly a guide that was followed--he didn't care enough to publish it while alive despite how careful he was about publication (I did a Ph.D. one Shakespeare and taught medieval, early modern and modern poetry for eight years before the siren call of web work). -jody -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ On Jun 19, 2008, at 3:06 AM, Jon Tan wrote: Historically each stanza in a poem is a paragraph. Layout (new lines) began punctuating paragraphs in the later Middle Ages. Prior to that the lines ran into one another with punctuation used to indicate where breaths and breaks in the running text occurred [1]. Syntactic punctuation was not commonplace until after Ben Johnson's English Grammar in 1640. That means that layout /is/ punctuation for modern poetry, so markup needs to reflect that. My recommendation would be for stanzas and line breaks for most verse. To do anything that returns stanzas to running text when CSS is disabled would break the syntax of the verse /unless/ lines are specifically punctuated with something other than a break at the end; a comma for example. is an alternative but does not punctuate line ends at all, except visually. It would be interesting to know how alternative browsers handle both s and single/ double line breaks in blocks. Do they inject a pause or other aural boundary? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] html vs. html
After much googling around (I was fascinated by this question) and much reading of various W3C documents here and there, I can say with about 97.3% certainty that the W3C has never drafted a recommendation that standardized file extensions. Most of their recommendations include URI examples that use the .html extension and the site itself appears to use .html extensions: http://www.w3.org/TR/xhtml1/Cover.html. The real story of why .htm and three letter extensions were ever used is told in a round about way here: http://en.wikipedia.org/wiki/Filename_extension . Given the history of filename extensions, I can see how someone might think that a three-letter extension is required (and maybe--for some strange reason--the server's settings do require html to be served as .htm and .html files are served differently). Whatever the case, the W3C doesn't recommend .htm as a standard. -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] premature to test/worry new site for IE8?
IE8's default setting will be to render web pages in standards- compliant mode. You can opt out of standards compliance with a meta tag. It was originally announced as the reverse. They changed their mind once the mob headed toward the castle in Redmond with pitchforks. Like most of us, If I could bill MS for all the time I've spent debugging/hacking web pages for IE, I'd be a rich man. But I've been using and testing the IE8 beta since it was released, and I'd hazard that if you're writing standards compliant (x)html and css, all should be well (more or less) with the final release. The efforts of the IE development team, while not always stellar in the past, genuinely seem to be going in the right direction. They're working with the Web Standards Project and other groups to ensure IE8 isn't the disaster that IE6 and 7 have been. -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ On Mar 21, 2008, at 3:52 AM, tee wrote: I am about to start coding for a new site, and client asked me to make sure my code will work for IE8, meaning when IE 8 comes out, she doesn't need to pay me extra to fix any problem that may occur in IE 8. Client is from a web media company, though I understand her concerns and that she has to answer to her client, but I just don't know how or if I should commit to such 'expectation'. Last time with IE 7, there was no problem and none of the sites I coded for her break when IE 7 came out. I think this version targeting thing really got people worry. Say, I code my CSS with best practice just like I'd always do, and treat IE browsers with CC should it be needed. Do I need to worry anything with IE8? It didn't occur to me to worry anything at all until client was making this request. Thanks! tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] generated source
Thanks, Paul, for the suggestion. Doctype, I don't think, is the issue. The doctype is set in the static XHTML that the Ajax builds on as XHTML strict. However, most generated source views remove the doctype, a phenomenon I asked about here: http://ask.metafilter.com/84314/Where-does-the-DTD-go . The W3C validator lets you re-declare a doctype if one is missing, http://validator.w3.org/#validate_by_input+with_options , but even using that option, many of my tags are still already unclosed from the generated source view. -jody On Feb 26, 2008, at 11:37 AM, Paul Bennett wrote: Hi Jody, I recall having a similar problem. The issue came down (from memory) to the doctype I was using. I was closing elements in xhtml style, while the doctype I was using was html. Firefox was happily removing the extraneous closing elements in the rendered source to fit the doctype. :) Paul *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] generated source
Does anyone have a preferred way to view and validate generated source code? By generated source I mean after Ajax, JavaScript, and so on have done their magic. I'm asking because I'm working on a web application for browsing network devices (close to 9000 routers, switches, WAPs, etc.) that relies on JavaScript (some homemade JS, jQuery, Ajax and JSON) to build virtually all the XHTML. Yet, when I view source via the debug "inspect element" feature in the latest release of Safari or using Pederick's web developer Firefox add-on, closed tags become unclosed. For example: Becomes: Yet viewing generated source in Firebug, that same meta tag remains closed. Firebug, however, doesn't have (or I haven't noticed?) a way to copy and paste source code for direct input validation to the W3C validator. This, then, is the ultimate goal: to get the generated source, copy it and paste it into a validator. I validated with static mockups prior to de-building the XHTML and giving it over to JavaScript, but I want to validate now to make sure I'm staying on track. Have others run into this problem? Thanks in advance, Jody -- Jody Tate Web Developer - UW Network Systems http://staff.washington.edu/jtate/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
