Daniel0

I couldn't find anything about it in the CSS1 specs, but it appears in CSS2: http://www.w3.org/TR/CSS2/aural.html I believe you are pretty much alone with that interpretation. If you can find somebody else who defines things the way you do then I'd like to see it though. As far as I can tell, consensus is that regular expressions are patterns written in a formal language that describes a text string. E.g. ^a\d+[a-z]$ matches a string that starts with an a, followed at least one digit, and ends with any lowercase letter a through z. You cannot express a checkerboard in that way. You cannot express the treats an organism must have in order to classify it as a mammal in that way. You can express text strings.

Because regular expressions are a particular type of patterns like a dog is a particular type of animal. You can express what I mean using PHP actually: class Pattern {} class Regex extends Pattern {} // and e.g.: class PCRE extends Regex {} // class POSIX extends Regex {} $pattern = new Pattern(); $regex = new Regex(); var_dump($regex instanceof Regex); // true var_dump($regex instanceof Pattern); // true var_dump($pattern instanceof Pattern); // true var_dump($pattern instanceof Regex); // false I'm talking about the same kind of taxonomy as you also use in biology to classify organisms (life>domain>kingdom, etc.) I believe there must be a widespread consensus that pattern and regex are synonymous for it to be true. Seriously though, would you call the following a regex? It's a pattern after all (white square followed by black square four times, new line, repeat eight times and reverse for each new line).

It may, or may not be true that other fields refer to regular expressions as something else than what it means in programming/computer science, but using a X's definition in a Y context doesn't really make sense and will only cause confusion. You can't just take a word, give it a new meaning and say that everybody else fails to understand its true meaning (the meaning you gave it). As I said before, I have never heard anyone who referred to something as a regular expression without it being in a programming sense. Patterns? Yes, but not regular expressions and I still do not agree that a pattern and a regex is the same thing. A regex is a pattern, but a pattern isn't necessarily a regex, in the same way that a dog is an animal, but an animal isn't a dog.

I know that, but that still doesn't make it regular expressions. Anything that's a pattern isn't regex. You don't call a sentence in English a regular expression either just because there are certain patterns in the language. Also, the way a word is usually used has to be the standard definition. You can't just make up your own definitions and claim you are still correct. I can't call a dog a table, a fork a bird, or grass a car. If I do that then people won't know what I am talking about because I use the words in a non-standard manner.

Yeah, I know about the various abstraction levels there are down to machine code, but I believe you are using a non-standard definition of the term "regex", CV. Mostly everybody else refer to regex as what is described in this article. It's true that PCRE is a particular implementation of regex and that other dialects exist (e.g. POSIX), but I've never seen anybody but you refer to regex as being "string parsing" all everything else that term encompasses.

Parsing a string doesn't make it regex. Regex can be used for that, but string parsing and regular expressions are not interchangeable things. Regular expressions have to be parsed as well, but if all parsing constitutes the use of regular expressions then you are sort of in an infinite loop. No computer knows what to do with ^fj(?=[a-z]{9})\d+$ by itself; it needs to be parsed itself.

I'm quite sure that the majority of interpreters do not use regular expressions for parsing and interpreting code. I'm not an expert on this though, so I'll return in some two years where I am hopefully studying computer science and have aced the compilers/interpreters course. I also very much doubt they pay the dudes over at Google a lot of money for just writing a couple of regular expressions. I'd assume that the algorithm for determining search relevancy is much more sophisticated than just figuring out which words there are on a page.

It's not so much about "short-cuts". You can make the header look any way you want (bold, another color, italic, or perhaps larger text). Most browsers just think that boldface, centered text is a good way to visually say "this is a header" and that works quite well. If you wish to change that visual appearance, however, then you can use CSS. In fact, those default styles are set using CSS. It's more or less the same difference between <i> and <em>. If you think that you have a better way of visually representing emphasized text then you can change it using CSS, but the tag will still indicate emphasis. <i> on the contrary would be ludicrous to change, because it only signifies that the text, for whatever reason, should be italic, and there is no other way to represent italicized text than setting it italic. <var> will often be represented in italic as well, but it's still different from both <em> and <i> because <var> represents a variable. <cite> is in italics as well, but it's also semantically different from the three tags before. Right, but spiders can better rank data if it carries a semantic meaning due to the fact that natural language processing is freaking difficult. Therefore, you should use HTML, not CSS, to express that. A table carries a semantic meaning, a div does not. This means that a div should not replace a table for representing tabular data. Of course, you can make a series of divs look like a table and its related tags, but that isn't the point. You can also make a table look like your divs+CSS (table based layouts). I never said you should, unless of course all content on the page is tabular. I said that tabular data should always be a table. CSS did exist, but browser support sucked. I still don't think that misusing HTML was a viable option. Browser vendors should have focused on CSS instead. Browser vendors also started to implement their own proprietary tags, such as the infamous <blink> tag, which later made it into the specifications because their usage became widespread. It's simply just bad decisions in the past because the focus was put in the wrong place. You are not writing essays in MS Excel and setting up spreadsheets in MS Word either. Despite the fact that you could do it, it is wrong. It's about using the right tools for the right job. This entire thing hasn't really anything to do with getting things look in a particular way, but in using proper semantic markup. The HTML5 draft takes this even further with more semantic markup elements such as <header>, <nav>, <section>, and <footer>. Also, I lied when I alleged that CSS doesn't carry semantics, because it can in a way do that. You could do <span class="whisper">something</span> and then .whisper{volume:soft}. The client is then free to use that or not. A regular text based browser such as Firefox would ignore it, but a screenreader would make the sound, well, softer. There are loads of other aural CSS properties, but their usage isn't very widespread. However, it is still only the content that's described in the HTML and then the presentation in CSS

Are you telling me that you would replace the following piece of markup with divs and CSS and call it cleaner (thus better)? <table summary="A list of the PHP Freaks users and information about them."> <caption>PHP Freas User List</caption> <thead> <tr> <th>User ID:</th> <th>Username:</th> <th>Email:</th> <th>Title:</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>jdoe</td> <td><a href="mailto:[email protected]">[email protected]</a></td> <td>Member</td> </tr> <tr> <td>2</td> <td>Daniel0</td> <td><a href="mailto:[email protected]">[email protected]</a></td> <td>Administrator</td> </tr> </tbody> </table> It is tabular data and it belongs in a table. This clearly defines the structure of the content in a semantic manner which will enable visitors that have no pragmatic understanding of the content's visual aids thus being able to translate it into meaningful and understandable content. Those visitors could be blind people using a screenreader or it could be search robots indexing your site. Anyone turning that into divs and make it look like a table don't really know what they are doing. They are just jumping the "tables=evil; divs=good" bandwagon without any real knowledge of how it works. You are also forgetting something, screenreaders and search engines cannot see all your fancy styles. A screenreader will not say: "Red text with a background image of a bear: Lorem ipsum dolor sit amet, consectetur adipiscing elit." It doesn't really matter whether most people use a browser that has CSS enabled. Your page should work regardless. I might find myself with a broken desktop environment and therefore need to use a browser like links from the terminal. The thing is that it's really easy to make things work with only the content layer, so I fail to see why somebody would not make it like that except due to ignorance. CSS is not and has never been a replacement of tables. Tables, on the contrary, have been a replacement for CSS but should never have been that. Today when things are turning and people are starting to use CSS for layout you hear all those people who try to convert legitimate tables into something else, which is really stupid actually. A benefit of using tables is for instance that if you use the <thead> then the table header will be repeated on each page when you print it (same goes for <tfoot> should you ever find a need for that). Screenreaders will also read aloud the content in a manner that makes you able to understand that it's a table of data. Incidentally, the same is true if you misuse tables, which will just confuse the heck out of them. Finally, I'd like to see your table->css+div conversion of the above table as well as notes on why it is cleaner and better. There must also be no accessibility drawbacks and it must behave like a table.

Well, not using tables for tabular data is just as wrong as using tables for non-tabular data. If you use CSS+divs to emulate tables then your page will be broken without the presentational layer. Dependencies must only exist in the way that a higher layer depends on a lower (e.g. CSS depends on HTML because the CSS is describing the HTML, and JS depends on CSS and/or HTML because it might change that based on certain circumstances). Not the other way around. Otherwise you will have accessibility and SEO issues. This page for instance works perfect even though it only uses the content layer (yes, I know browsers have built-in default styles).

I'm not so sure about that. In this article, point 6 out of 13 reasons why CSS beats out tables: [...] No, you're misunderstanding me. CSS is irrelevant in regards to SEO. CSS simply specifies how things should look. You typically split a webpage up in three layers: content (HTML), presentation (CSS), behavior (Javascript). Search engines only care about the bottom-most layer, the content layer. It is said that each consecutive layer adds a higher user experience (as long as you do not overdo it obviously), but the page must be usable being viewed with only the bottom layer, both for accessibility reasons, but also for SEO reasons. I said that semantics have an effect on SEO, and that is essentially what you are talking about as well. Try to look up the word: "the meaning, or an interpretation of the meaning, of a word, sign, sentence, etc." Using a table for non-tabular data is not semantic because a table implies tabular data. <em> implies emphasized text, <strong> implies strongly emphasized text, <i> implies nothing as it is a presentational element and should thus not be used. Using e.g. the <strong> and <em> tags a screenreader or search engine can see that the content these tags encompass has a higher importance than the surrounding text. Likewise, <h1> through <h6> defines the structure of the page via semantics (note to PHP Freaks authors: which is why you must follow my publishing guidelines and not use the tags above h4 as they are already used). You can remove the stylesheets from a webpage and a search engine wouldn't care because it's not taking that into consideration when indexing it; it has no effect on SEO. CSS doesn't beat tables, semantic markup beats them. CSS only matters if you want your webpage to look nice.

Semantic markup might. CSS has no effect on SEO.

Ah but the ToS does not specifically prohibit you from having an insecure LAN. It specifically says "... allow others to ...". I suppose that depends on how you interpret it. Leaving it open creates a kind of "ACL-allow" for people to use it in the "Can X do this? [Yes/No]" sense where the default is "Yes". I meant your own perception of your experience. If you consider yourself experienced then you should know. If not, then you should have RTFM because that's what its for - figuring out how your product works and how you are supposed to use it. Those two sentences contradict each other. If most people do not bother with manuals, then it would not be logical to assume one would read the manual. But nonetheless, making a statement like "most people do not bother with manuals" is speculation, and would be treated as such, in court. The only reason I point out the inconsistency is because you believe that most people don't bother, and yet say it's logical to assume that they would. I don't think it's contradictory. A manual is meant to be read if you do not already possess the knowledge it contains. You may for instance find that the manual of your microwave says that you shouldn't dry your pets in it. Apparently that is sufficient to protect the manufacturer from lawsuits. This sets a precedent for that it would be logical to assume that the end user would have read the accompanying manual of a product. It's your own choice if you choose not to read important information in the same way that we still punish people who broke our rules here even if they didn't bother to read them. If you genuinely didn't know, and there was nowhere in the product (or the things that follow the product (e.g. manual)) stated that not encrypting the signal would enable everybody within range to use it and that it could potentially create a security risk, then you would have a good case, but I think most manuals (or installation guides) say this. Checking this would be fairly easy in the case of a dispute. If the manual didn't mention this then it sucks.

Just to set things straight, on PHP Freaks you are NOT allowed to copy our tutorials/blog posts without the explicit permission from an administrator AND the original author. It wouldn't be very difficult to get that permission, but without it we consider it copyright infringement. All it would require to get my permission would be accreditation to the author and a visible link to the original posting. E.g. something along the lines of "This tutorial was originally written by John Doe at PHP Freaks. Link to original tutorial: <url>" at the start of the tutorial would be fine (still need permission though). I'm sure most other sites would want the same thing, but if you're in doubt then you better ask before acting. Edit: I suppose we could consider publishing it under this license.

How am I going to prove my innocence? Dunno how you guys do it over there, but over here, law is innocent until proven guilty. All I have to do is say I was ignorant. Burden of proof is on them. Yeah, we are innocent until proven guilty, the fact that you left it open even though the ToS explicitly prohibited it remains. Sure, you could claim ignorance, but I could also claim that I didn't know shooting you could kill you. It's just a matter of whether your ignorance is believable or not. If you were considered an experienced user then it would be difficult to believe you didn't know. If, however, you weren't then the aforementioned guide would tell you, and if not then at least it would be written somewhere in the manual. If you claim to be an inexperienced user of that type of equipment then it would be logical to assume that you would read the manual to figure out how to use your equipment properly. I know most people do not bother with manuals, but that isn't really an excuse in my opinion. Otherwise every single crime or contractual breach could be voided by ignorance. I'm quite sure your insurance company wouldn't cover your losses if someone stole your things if you forgot to lock your door. In Denmark they wouldn't, and here a locked door is what separates burglary from theft.

But I suppose that if they wanted to be asses then they could just terminate a such person's account. How are you going to prove that you were ignorant and didn't leave it open for public usage intentionally? Any wireless router I've ever used and/or setup has always presented me with a guide advising me to turn encryption on though, so I fail to see how some people don't do it unless they perhaps are buying enterprise grade routers where you expect a certain level of competency of the end users. I wouldn't imagine anything would happen. You wouldn't be charged with murder if I stole your gun and shot someone with it either. I suppose you're right though. Leaving my door unlocked (or even letting someone in) doesn't mean that everybody may steal my shit.

Does that mean that you are violating ToS if you are too stupid to encrypt your signal?

You mean like this? http://www.phpfreaks.com/tutorial/debugging-a-beginners-guide

FYI, if I didn't make it clear, everybody can make suggestions. It doesn't have to be the ones suggested by staff. We'll pick the best ones next year, so make sure you post your suggestions if you have some.

Please do not post links to download copyrighted material that you do not have the right to redistribute yourself.

Why don't you ask your ISP? There is no way we can know as each ISP has its own policies. They may or may not require you to upgrade to a corporate account or something like that.

Could you display the markup you used to embed it? You also need to make sure your browser knows what to do with mp4 files.

Setup A records and a vhost for their domain.

That's why one should read the stickies that tell such information. Stickies are there to be read. They often contain important information and the answers to questions that have been asked a lot.

I find that feature somewhat useless. How is the forum going to know if you're still writing or not?